> 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/contract-controls.md). # Contract controls A direct list of privileged actions, immutable settings, team commitments and operational dependencies. The Pons token, the team treasury wallet, the lottery contract and the buyback burner are separate pieces. Their permissions must not be confused. ## Launch sequence `$LOTRIO` is launched on Pons with the team's treasury wallet named as the Pons creator-fee recipient **inside the launch transaction**, in which Pons deploys the token and its bonding curve. The buyback burner and the lottery contract are deployed afterward in two transactions. There is no fee collector contract and nothing to bind: the fee recipient is a wallet. ## Treasury wallet (team-controlled) The treasury wallet receives 100% of the creator fees (≈1.7% of trading volume). It is controlled by the team, so these are **operational commitments**, not rules enforced by code: * before every draw, the keeper sends 80% of the creator fees accrued since the last draw from the treasury into the lottery; * the remaining 20% is used for marketing and operations; * the treasury stays the Pons creator-fee recipient and Pons' own vesting buyback stays off. They are verifiable on-chain: every deposit is a `TreasuryFunded` event on the lottery from the published treasury address, the fees it earns are Pons fee-escrow credits to that address, and any creator-fee-recipient change is visible 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 treasury wallet is permanently excluded from WIN POWER: it can never win. ## Lottery contract (no owner) The lottery has no owner, no admin and no withdrawal function. Nobody — including the team — can withdraw the pot, change the odds, the payouts or the 15-minute interval. Deployment permanently fixes: * the `$LOTRIO` token; * the transfer relay; * the buyback burner; * the 0.05 ETH minimum pot; * all excluded system addresses, including the treasury wallet. These rules are constants in the code: * 1 WIN POWER per 10,000 `$LOTRIO`; * the 15-minute interval and 5-block reveal delay; * 50% / 30% / 15% prizes and the 5% buyback and burn; * 30% / 20% / 10% WIN POWER winner deductions; * 25% deduction recovery after 24 / 48 / 72 / 96 completed prize draws. ETH can enter the lottery from any address and is recorded as a `TreasuryFunded(from, amount)` event. ETH leaves the lottery only as prizes and as the 5% buyback share sent to the burner. If that transfer fails, the ETH stays in the pot for the next draw and the lottery emits `BuybackDeferred`. The transfer relay can report canonical token transfer edges. It cannot provide balances or WIN POWER: the lottery rereads balances from the immutable Pons token, rejects duplicate transfer identifiers and verifies winner proofs against the committed Merkle-sum root. Winner deductions use the verified snapshot WP. Transfer relay processing pauses during an active draw and any bounded recovery sweep, then resumes in canonical order so a post-snapshot transfer cannot leave the deduction on an empty wallet. All draw maintenance, claims, holder repairs (`syncAccount`), recovery processing and expired-draw resets are permissionless. ## Buyback burner (no owner) The buyback burner has no owner and no withdraw function. ETH can leave it only as a `$LOTRIO` purchase, and every purchased token goes straight to the dead address `0x000000000000000000000000000000000000dEaD`. * `buyAndBurn(minTokensOut)` spends the whole ETH balance on the Pons bonding curve before graduation and in the Pons V4 pool afterwards. It 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. ## Pons token and market Token creation, fee collection, bonding-curve trading, graduation and liquidity are handled by Pons contracts, not by the project: * the token is a plain fixed-supply ERC-20 with 1,000,000,000 tokens; * the bonding curve holds the supply until 4.2 ETH is raised; * at graduation Pons creates a Uniswap V4 pool and locks its liquidity permanently; * every buy and sell pays 2%: a 1% Pons trading fee plus a 1% creator tax that Pons fixes forever at launch; * after graduation, Pons sweeps pool fees to the treasury at most once per hour; * Pons' own optional buyback feature, which vests bought tokens to the creator over 5 years, is disabled for `$LOTRIO`. The 5% buyback and burn is a separate mechanism run by the burner above. Pons platform and pool controls are external protocol dependencies. Pons' own documentation describes Pons V2 as unaudited. ## Operational dependencies | Dependency | If unavailable | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Keeper | Pot funding, draws, transfer relay and burns are delayed. The owed 80% share keeps accumulating; `syncAccount()`, draw steps and recovery functions remain publicly callable, and anyone can call `buyAndBurn` after 7 days without a keeper burn | | Treasury wallet | The pot is funded only by deposits from the treasury. If it is short of ETH, the keeper deposits what it can and the rest stays owed | | RPC provider | Website data and keeper transactions may be delayed | | Pons fee-sweep operator | After graduation, pool fees reach the treasury only when Pons sweeps them (at most hourly); the keeper pre-funds from an estimate in between | | Pons curve and V4 pool | Trading, new fee revenue and buybacks depend on Pons contracts | | Frontend hosting | Contracts remain on-chain, but the normal interface may be unavailable | {% hint style="warning" %} The repository contains automated tests, an internal engineering review and a mainnet-fork rehearsal of the lottery and buyback burner against the live Pons contracts. This is not an independent third-party audit or formal verification. Pons describes Pons V2 itself as unaudited. {% endhint %} --- # 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/contract-controls.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.