> 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/governance.md). # governance GetRekt's governance design separates administration, emergency controls, price publication, fee collection, and package upgrades. The intended administrator is a **2-of-3 Sui multisig**. Changes to supported risk parameters and market package upgrades have a **48-hour delay** in the current implementation. These protections take effect only after deployment and verification of capability ownership. No GetRekt deployment has been verified. The requested 2000× limit, $REKT reward curve, and referrals are also pending implementation; see [implementation status](broken://pages/c7eabe8af8c3f2ae7c1c1dce69dad717e5d1ac7a). ## Who can do what? | Role | Current implementation authority | Limits | | ------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | GuardianCap holder | Stop new positions and cancel a pending risk proposal | Cannot withdraw collateral or choose an arbitrary settlement price | | AdminCap holder | Propose maximum leverage, position and total notional limits, and price-age limits | 48-hour delay; ordinary setters cannot exceed code-level bounds | | OracleCap holder | Publish Lighter bid/ask, source time, and increasing sequence | Must pass price checks; remains a trusted relay | | Pyth refresh caller | Refresh the reference from the official BTC PriceInfo | Permissionless; cannot supply an arbitrary reference price | | Trader | Manage their own positions, eligible claims, stakes, and accrued rewards | Ownership, amount, price, and deadline checks apply | | Any caller | Trigger eligible liquidation, FIFO harvest, and LP overflow processing | Recipient, eligibility, and payment order are fixed by the contract | | Fee recipient | Withdraw accrued developer fees | Address fixed at Vault creation; no authority to take arbitrary collateral | | Upgrade governor | Propose a package digest and authorize/commit an upgrade after the delay | The actual UpgradeCap is held inside the wrapper | The unchanged market code still has a 2100× hard ceiling. GetRekt's requested product ceiling is 2000×; publishing these documents does not change that constant. An emergency pause cancels an older pending risk proposal. Resuming requires a fresh AdminCap proposal, the 48-hour wait, and then permissionless execution of `apply_risk`, which also clears the pause. Pausing blocks new positions; it does not itself disable valid closes. There is currently no separate permanent market-retirement operation or administrator-selected frozen settlement price. ## Upgrade protection The deployment flow must put the real market UpgradeCap inside the timelock and destroy the governance package's own UpgradeCap. This makes the governance wrapper itself immutable. Retaining an external upgrade path would undermine the stated delay. Giving AdminCap to a multisig is not sufficient on its own. Operators must also verify the market UpgradeCap, immutable governance package, governor and guardian addresses, delay, and on-chain installation receipt. An upgrade can change future protocol rules. A timelock provides notice and a delay; it does not make upgradeable rules permanent. ## Can $REKT be transferred or issued arbitrarily? The current reward implementation is a **nontransferable ledger**, not a standard Sui Coin. It has no public transfer function, transfer toggle, arbitrary administrator mint, or total-supply setter. Reward issuance is called by package settlement code for eligible cash and debt losses. There is no fixed 21-million-token cap. The new $REKT design starts at 10,000 tokens per 1 USDC of gross eligible loss and halves the rate after each $10 million of cumulative gross eligible platform loss. Cash and debt losses advance the same counter, before fees or referral allocations. That curve is documented but not implemented. Its counter is distinct from LP cash, outstanding claims, and referral payouts. See [tokenomics](broken://pages/0da545b31b48891659a4cd0a1832dae219999577). The current fee-sharing and $5 million LP overflow constants have no ordinary administrative setter. Overflow additionally requires no open positions and no queued claims; idle reserves from periods with no stake are not retroactively distributed. These are current implementation facts, not confirmation that the new referral design has been integrated. See [referral fees](broken://pages/4ae98f6aa1e3c0a457110b4f9eefb1d3448a99a6). ## Oracle authority and disclosure A relay can stop publishing or select prices within accepted bounds. Pyth limits the accepted range but does not remove this authority. Poor price quality may prevent existing positions from closing as well as prevent new positions; this availability limitation must be disclosed. Before launch, publish all capability IDs and owners, multisig signers and weights, pending proposals, and upgrade history. Unknown addresses must remain marked as undeployed rather than replaced with examples. --- # 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/governance.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.