TRN↔BRN Internal AMM

The TRN↔BRN Internal Automated Market Maker (AMM) is a closed-system swap mechanism that handles internal engagement-based token flows between the platform’s two primary tokens: TRN and BRN. This AMM is not publicly exposed and does not integrate with any external exchanges. Its sole purpose is to provide liquidity and accounting integrity for user actions involving burns, retrns, and moderation feedback while maintaining systemic equilibrium.

---

Purpose

• Maintain a 1:1 peg between TRN and BRN for internal platform actions.

• Isolate burn mechanics to a mirrored token (BRN) to prevent circulating supply inflation of TRN.

• Facilitate tracking of burned engagement TRN and earmark it for redistribution via DAO or auditing.

• Allow users to perform retrns and brns without directly destroying TRN—instead, converting TRN to BRN which is later burned through Merkle reconciliation.

---

Key Properties

Property	Value
Swap Direction	TRN → BRN for user-initiated burns, flags, and retrns
Reverse Swap	BRN → TRN allowed only during refund logic (e.g., burned boosted posts)
Peg Enforcement	1 TRN = 1 BRN (strict)
Public Accessibility	Not publicly accessible; private contract only
Trading Limits	Swaps are rejected if they exceed ±2% daily deviation impact
Price Movement Protection	Hard rejection on large swaps; triggers rate-limiting logic
Integration	Controlled by the TRNUsageOracle and BurnRegistry modules
Slippage	0% allowed (swap is 1:1 only)
Listing Policy	BRN is not listed on public exchanges

---

Transaction Flow

1. User burns a post or flags content.

   • The platform routes a request to the BurnRegistry.

   • BurnRegistry invokes the TRN↔BRN AMM to swap 1 TRN → 1 BRN.

2. BRN is staked until the next Merkle drop.

   • BRN is recorded on the user's interaction ledger.

   • It is not transferable or visible to the user.

3. At Merkle batch processing (UTC+0):

   • The BRN is burned permanently.

   • The DAO may receive a share of the total burned value, depending on system rules.

4. Refund scenario for boosted content:

   • If a boosted post is burned, the remaining unspent TRN is returned.

   • This may involve BRN → TRN reversal under controlled, internal-only logic.

   • These reversals are strictly handled by TRNUsageOracle ledger rules.

---

Economic Design Considerations

• The AMM enforces closed-loop internal liquidity, ensuring BRN can never escape the system or be traded externally.

• By converting user engagement actions into BRN, the system defers final TRN supply changes until Merkle reconciliation, enabling safe batch-based accounting.

• Boosting funds are excluded from being affected by burns until spent; unspent TRN from burned boosted posts is returned to the booster.

---

Governance Constraints

• All AMM parameters (max swap cap, rate-limits, BRN emission ceilings) are DAO-configurable via governance proposals.

• The DAO monitors BRN burn totals and can audit swap usage through the BurnRegistry.

---

Key Modules

Module	Description
TRN↔BRNInternalAMM	Core contract facilitating 1:1 TRN↔BRN swaps. Not exposed externally.
BurnRegistry	Tracks burn events, interacts with the AMM to mint BRN and logs metadata.
TRNUsageOracle	Ensures that the user is not overdrawing funds; acts as arbiter of eligibility for swaps and reversals.
BoostingModule	References BRN data in determining unspent budgets and refund triggers.

---

Rejection Conditions

• Any attempt to execute a swap that would cause:

  • More than a 2% impact on daily TRN or BRN flow.

  • Violation of Merkle-locked balances.

  • Unauthorized direct BRN interactions.

• These are blocked by the TRNUsageOracle, not the AMM contract itself.

---

Additional Notes

• Pinning does not use BRN and incurs no token transfer or staking.

• Burned posts result in forfeiture of all remaining unspent TRN from boosted budgets; these are routed back to the booster via Merkle allocation.

• Users never hold BRN directly. All swaps are tracked in internal ledgers for auditability.