> For the complete documentation index, see [llms.txt](https://docs.lotrio.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lotrio.app/trust-and-verification/pons-architecture.md). # How LOTRIO runs on Pons How the treasury wallet, the lottery contract and the buyback burner plug into a token launched on the Pons V2 launchpad. `$LOTRIO` launches on the [Pons V2 launchpad](https://www.ponsfamily.com/launchpad) on Robinhood Chain (chainId 4663). Pons deploys and owns the market. The project adds two small ownerless contracts — the lottery and the buyback burner — plus a treasury wallet that receives creator fees and a keeper that runs the cycle. {% hint style="warning" %} **Launch pending.** No production addresses exist yet. They will be published only on [Launch status & official links](/trust-and-verification/launch-status.md). {% endhint %} ## Who owns what | Component | Deployed and controlled by | Role | | ---------------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `$LOTRIO` token | Pons | Plain fixed-supply ERC-20, 1,000,000,000 tokens. No transfer hooks and no project-specific code. | | Bonding curve | Pons | Per-token contract that holds the supply and prices every trade before graduation. | | Uniswap V4 pool | Pons | Created at graduation (4.2 ETH raised). Pons locks the liquidity permanently. There is no Uniswap V2 pair. | | Pons fee escrow | Pons | Holds the ETH that Pons credits to each token's creator-fee recipient until it is claimed. | | Treasury wallet | Team | Pons' creator-fee recipient for `$LOTRIO` — a wallet, not a contract. Receives all creator fees; 80% is moved to the lottery before every draw. | | Lottery contract | Project, **no owner** | Tracks WIN POWER, runs the draws and pays winners in ETH. | | Buyback burner | Project, **no owner** | Receives 5% of every pot, buys `$LOTRIO` on Pons and sends it to the dead address. | | Keeper | Team | Bot that relays transfers, funds the pot from the treasury, advances draws and triggers burns. | ## Trading fees Every buy and sell — on the bonding curve and, after graduation, in the V4 pool — pays **2%**: | Part of the 2% | Share of trade volume | Goes to | | --------------------------------------------- | --------------------: | ---------------------------------------------- | | Pons trading fee — protocol share (30% of 1%) | 0.3% | Pons | | Pons trading fee — creator share (70% of 1%) | 0.7% | Treasury wallet | | Creator tax (100% of 1%) | 1.0% | Treasury wallet | | **Creator fees** | **≈1.7%** | | | → lottery pot (80%) | 1.36% | Lottery contract, every draw | | → team (20%) | 0.34% | Stays in the treasury (marketing / operations) | Pons fixes the 1% creator tax forever at launch. Wallet-to-wallet transfers pay no fee. ## Revenue flow ``` Before graduation Trade on the Pons bonding curve -> Pons credits the creator fees to its fee escrow for the treasury -> the treasury claims the ETH After graduation Trade in the Pons Uniswap V4 pool -> fees accrue in the Pons pool hook -> Pons' fee-sweep operator converts them to ETH and credits the treasury, at most once per hour Every 15 minutes, right before the draw -> keeper totals creator fees accrued since the last draw (credited by Pons + not-yet-swept pool fees valued at each trade's price) -> 80% is sent from the treasury to the lottery (TreasuryFunded event) -> 20% stays with the team ``` Because Pons sweeps pool fees only hourly after graduation, the keeper **pre-funds** the pot from the treasury's own ETH and **reconciles** when each sweep lands: the real credited amount replaces the trade-time estimate and later deposits are adjusted so the running total matches 80% of the creator fees actually earned. The pot on the website therefore grows live and freezes at each draw. If a round's pot would be below 0.05 ETH, nothing is deposited, the round is skipped and the 80% share keeps accumulating for the next round. If the treasury is temporarily short of ETH, it deposits what it can and the rest stays owed. {% hint style="warning" %} The 80% transfer is performed by the team's keeper from the team wallet. It is an operational commitment that anyone can check on-chain, not a rule enforced by a contract. See [Fairness explained](/trust-and-verification/security-and-fairness.md#what-you-trust-the-team-with). {% endhint %} ## The treasury wallet The treasury wallet is named as the Pons creator-fee recipient in the launch transaction. It is a team-controlled wallet, not a contract. * It receives 100% of the creator fees. The keeper moves 80% into the lottery before every draw; 20% funds marketing and operations. * It is permanently excluded from WIN POWER in the lottery, so it can never win even if it holds `$LOTRIO`. * As the current recipient, it is the address Pons lets change the creator-fee recipient or switch on Pons' own vesting buyback. The team commits to doing neither; any such change is visible on-chain on the Pons factory. * Pons' own admin (a 2-of-3 Safe multisig) can also queue a recipient change for any Pons token, which only takes effect after a 3-day timelock and is visible on-chain as a pending change until then. ## The lottery contract The lottery contract has no owner and no admin. Every parameter is immutable or a constant: * 1 WIN POWER per 10,000 `$LOTRIO` held; * a draw every 15 minutes, a 0.05 ETH minimum pot and at least 3 eligible wallets; * three different winners paid 50% / 30% / 15% of the pot in ETH; * 5% of the pot sent to the buyback burner; * winner WIN POWER deductions of 30% / 20% / 10%, recovering 25% every 24 completed draws; * future-blockhash commit-reveal randomness. The lottery accepts ETH from anyone and records each deposit as a `TreasuryFunded(from, amount)` event. ETH leaves it only as prizes and as the 5% buyback share. A prize that cannot be pushed to a wallet stays reserved for that wallet and can be withdrawn with `claim()`. If the 5% cannot be pushed to the burner, it stays in the pot, rolls into the next draw and the lottery emits `BuybackDeferred`. ## Buyback and burn The buyback burner is a separate immutable contract with no owner and no withdraw function. ETH can leave it only as a `$LOTRIO` purchase. * `buyAndBurn(minTokensOut)` spends the burner's whole ETH balance buying `$LOTRIO` on the Pons bonding curve before graduation and in the Pons V4 pool afterwards. Every token goes straight to the dead address `0x…dEaD`, and the call reverts if fewer than `minTokensOut` tokens would be burned. * Only the keeper, the burner's immutable `operator`, can call it, so it can apply slippage protection against sandwich attacks. * If the keeper has not burned for 7 days, anyone can call it, so the ETH can never be stuck. * The purchase pays the normal 2% Pons fee like any other buy, so 1.7% of it returns to the treasury as creator fees. Pons' own optional buyback feature, which vests bought tokens to the creator over 5 years, stays disabled for `$LOTRIO`. The 5% buyback and burn is this separate contract. ## Holder accounting The Pons token has no hooks, so it cannot notify the lottery when balances change. Instead, the keeper relays the token's canonical `Transfer` events to the lottery. The relay can only report that a transfer happened: it cannot set balances or WIN POWER. The lottery always rereads `balanceOf` from the token. * Each transfer is identified by transaction hash and log index and is processed only once. * The relay moves a proportional share of any winner deduction with wallet-to-wallet transfers. When tokens go to an excluded address — which is what a sell on Pons does — that share is released instead. * Relay processing pauses while a draw is in progress, then resumes in canonical order, so a transfer after the snapshot cannot leave a deduction behind on an empty wallet. * Anyone can call `syncAccount(wallet)` to reread a wallet's balance at any time. * Trades made before the lottery is deployed are picked up by the keeper's balance replay from the launch block. ## Excluded from WIN POWER Addresses that hold supply, liquidity or fees for the system never receive WIN POWER: the zero address, the token itself, the lottery, the dead address `0x000000000000000000000000000000000000dEaD`, the `$LOTRIO` bonding curve, the team treasury wallet, the buyback burner and these Pons system contracts: | Pons contract | Address | | -------------------------- | -------------------------------------------- | | Factory | `0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e` | | Pool hook | `0xE5e702641Ea86F4ae6cC3cDaeD2B886f976Be044` | | Fee escrow | `0xd3AFEB2a57f70eF218Aa82451c51B2fb0416Ac9e` | | Buyback vault | `0x42df2a798f82289E177311362e8f5ccC45c1219c` | | Launch locker | `0x267444D099b10fB5Ed7c3Cc7B7c767AdcA574952` | | Launch router | `0xe33E9E479dF8802cb0866d5d05258bEc4cF62948` | | Launch deployer | `0x3711ceA4feaDE896C913C68F01Eda97Cb06D1A42` | | Graduation executor | `0xC7819B64A1dAECD7eC19856d026cb14EfBd89046` | | Graduation guard | `0xf5695117b99B6f6401e67d4195BD653628176C6C` | | Uniswap V4 PoolManager | `0x8366a39CC670B4001A1121B8F6A443A643e40951` | | Uniswap V4 PositionManager | `0x58daec3116aae6D93017bAAea7749052E8a04fA7` | | Permit2 | `0x000000000022D473030F116dDEE9F6B43aC78BA3` | The exclusion list is fixed when the lottery is deployed. Anyone can check an address with `excludedFromLottery(address)`. ## Launch order 1. The team launches `$LOTRIO` on Pons with the treasury wallet as creator-fee recipient. Pons' own buyback option is disabled. 2. The buyback burner and the lottery contract are deployed (two transactions, nothing to bind), with the curve, the treasury, the burner and every Pons system address excluded from WIN POWER. 3. A read-only verification script checks the deployment. It fails unless Pons names the treasury as fee recipient, no fee-recipient change is pending, the creator tax is 1%, Pons' own buyback is off, the lottery's token, relay, 0.05 ETH minimum pot and 5% buyback match, the burner is wired to the right token, curve, pool and operator, and every system address and the treasury are excluded. 4. The keeper starts relaying transfers, funding the pot from the treasury, running draws and burning the buyback share. ## Limits of this setup * Pot funding is an operational commitment of the team: the treasury receives the creator fees and the keeper moves 80% into the lottery. Deposits are public `TreasuryFunded` events, but no contract forces them. * Trading, graduation, liquidity and fee delivery run on Pons contracts that the project does not control. Pons' own documentation describes Pons V2 as unaudited. * After graduation, Pons sweeps pool fees at most once per hour; between sweeps the keeper pre-funds from an estimate. * The buyback is a market purchase. The keeper protects it with a minimum output; a public call after the 7-day fallback sets its own minimum and may get worse execution. * The lottery and buyback burner contracts have automated tests, an internal review and a mainnet-fork rehearsal against the live Pons contracts. Neither has had an independent third-party audit. {% content-ref url="/pages/brwHMXgzuyveRAo7nCaP" %} [Contract controls](/trust-and-verification/contract-controls.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.lotrio.app/trust-and-verification/pons-architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.