> For the complete documentation index, see [llms.txt](https://docs.getrekt.trade/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.getrekt.trade/implementation-status.md). # implementation status **GetRekt is not deployed for public trading.** This book records the new product specification. Documentation changes do not update Move bytecode, wallet balances, published packages, or the existing trading simulator. ## Specification versus repository | Feature | GetRekt specification | Current repository | | -------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- | | Brand | GetRekt · getrekt.trade · $REKT | This book is renamed; older app screens, package names and operational paths remain | | Maximum leverage | 2000×, subject to oracle and market limits | Hard ceiling remains 2100× | | Initial emissions | 10,000 $REKT per gross eligible USDC loss | 100 legacy reward units per eligible USDC basis | | Emissions schedule | Halve every 10M cumulative eligible USDC losses, platform-wide | Old tracked-LP curve and per-Vault rewards state | | Loss basis | Gross realized loss, including debt loss and full hard-bust margin | Normal close can use loss net of a charged fee | | Cash-loss allocation | Deduct 2%, then split the remainder 30% referrer / 70% LP | No referral system; existing cash-loss fee is waived while the queue is nonempty | | Debt-loss referrals | None; debt loss still earns $REKT | Debt-loss minting exists under the old curve; referrals do not exist | | Zero initial LP and FIFO | Retained | Local Move and simulator implementation; no production deployment | | Reward transfers | Internal, nontransferable rewards unless a separate release changes this | Ledger only; no standard wallet-transferable REKT Coin | | Sui settlement and pricing | Move settlement, Lighter prices, Pyth quality checks | Modules and SDK present; production oracle operation remains unverified | | Cross-chain deposits | Native USDC from Ethereum and Base through CCTP V2 | Builders and guards exist; complete user-owned burn → receive → open flow is unproven | | Sessions | Explicit wallet approval unless scoped sessions are implemented | No production delegated trading-session system | ## Economic choices in this edition The 2% loss fee is retained **before** the referral split. A referred 100 USDC cash loss therefore allocates 2 USDC to fees, 29.4 USDC to the referrer, and 68.6 USDC to LP cash. A debt loss creates no referral cash or referral claim. To give “each 1 USDC lost earns 10,000 $REKT” a consistent meaning, the new specification uses gross realized losses before fee or referral allocation. Eligible debt losses advance that same global counter. These definitions must be implemented together; the legacy net-loss basis cannot be retained silently. The new cash-loss allocation is reserved before LP cash pays the FIFO queue. This is a change from the legacy queue-related cash-loss fee waiver. FIFO continues to order trader claims against the resulting LP cash; it does not give those claims a right to the referral or fee reserves. There is no promise that every dollar lost becomes immediately available to queued winners. No-referrer losses send all post-fee cash to the LP. The proposed referral binding, integer rounding and claim mechanics are specified in [Referral fees](broken://pages/4ae98f6aa1e3c0a457110b4f9eefb1d3448a99a6); they are implementation requirements, not existing capabilities. The 2% adjusted-profit fee and the conditional 5M USDC LP overflow rule remain separate from the new emissions schedule. ## Required before these features can be called live Move, SDK, indexer, front end and deployment manifests must agree on the new rules. Validate boundary-crossing emissions, global counter continuity, referral binding, duplicate settlement protection, reserve conservation, FIFO ordering, and upgrade migration. Then complete the real testnet deposit-to-position flow and publish its transaction evidence. No mainnet readiness, external audit, guaranteed solvency, or error-free operation is claimed. [Launch checklist](broken://pages/778926bacf8bfd7e0a0cce9f9bc284dec32ce34b) tracks release evidence; [Contract addresses](broken://pages/27e7fe412ab3cc77271699f3eac06e4761ddd6b0) contains the deployment status. --- # 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.getrekt.trade/implementation-status.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.