> 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/security.md).

# security

GetRekt cannot promise zero errors, guaranteed withdrawals, or unconditional access to maximum leverage. Its engineering goals are reproducible accounting, visible authority, explicit rejection rules, and independent verification before public funds are accepted.

No production deployment or independent audit is complete. The new 2000× product limit, $REKT issuance schedule, and referral allocation are still documentation changes. See [implementation status](broken://pages/c7eabe8af8c3f2ae7c1c1dce69dad717e5d1ac7a).

## Core invariants

| Risk                          | Required protection                                                                    |
| ----------------------------- | -------------------------------------------------------------------------------------- |
| Unbacked USDC accounting      | Count only received Coins as cash; reducing a debt is not a cash deposit               |
| Misuse of collateral          | Keep open-position cash collateral separate from distributable LP cash                 |
| FIFO bypass or double payment | Preserve earlier claims and prevent a consumed claim from also being paid              |
| Manipulated or stale prices   | Reject wrong-market, stale, future, or replayed data; enforce uncertainty limits       |
| Excess operator authority     | Separate and disclose upgrades, administration, oracle publication, and fee collection |

## High leverage and price availability

At 2000×, small price errors matter. Frequent updates alone do not establish suitability: bid/ask width, confidence, tick size, relay integrity, commit latency, clocks, and liquidation delays all affect the result.

Lighter is a data source, not an execution venue for GetRekt positions. Its BBO reaches Sui through a trusted relay. Pyth adds independent checks but does not prove that every accepted Lighter quote is genuine. Market-quality checks can stop both new positions and price-dependent settlement of existing positions.

The implementation must demonstrate acceptable uncertainty and liquidation behavior at each enabled leverage. Disabling checks to make a test pass is not evidence of safety.

## Unpaid profits and zero initial LP

FIFO defines payment order; it does not guarantee that future losses will supply sufficient USDC. Profitable traders, hostile price activity, or a sustained liquidity shortfall can expand the queue. Debt collateral and rewards do not replace missing cash.

The chosen model allows debt-funded positions and rewards on eligible debt losses. This separates reward issuance from new USDC entering the LP. The proposed referral model applies only to actual-USDC losses: take a 2% fee first, then split the remainder 30% to an eligible referrer and 70% to LP. Debt losses generate no referral payment. A referred 100 USDC cash loss supplies only 68.6 USDC to LP; an unreferred one supplies 98 USDC. These allocations precede FIFO payment, replacing the legacy cash-loss fee waiver while claims are queued. The changed queue funding needs separate economic review. See [referral fees](broken://pages/4ae98f6aa1e3c0a457110b4f9eefb1d3448a99a6).

## Economic attack surface

Testing must cover self-referrals, coordinated opposite positions, repeated debt-position cycles, flash staking, stake timing, rounding, losses spanning issuance halvings, duplicate settlement, and claims consumed before payment. Cumulative eligible loss, token supply, tracked LP value, and actual USDC are distinct quantities.

An existing stress scenario against the **legacy 2100× model** found a conditional path where two opposite 100-USDC positions, a favorable 20-basis-point move, and settlement ordering preserved 200 USDC of combined available cash while producing an additional 234.713554 USDC unpaid claim and 10,000 legacy reward units. Repeated favorable debt cycles could expand reward issuance further. This was not a risk-free strategy, and its numbers are not a simulation of the new $REKT schedule. It demonstrates why cash conservation and unit tests alone cannot establish economic safety. The reproducible case is in `research/economic-stress.md`.

## Verification before release

Required evidence includes Move tests, independent JS/Move comparisons, stateful accounting tests, oracle replay, cross-chain interruption recovery, sustained testnet operation, and external contract and economic reviews. The new issuance and referral logic needs its own tests and review; old passing results do not cover it.

An upgrade must preserve existing positions, claims, signature domains, and bridge nonces or provide an explicit verified migration. Resetting a contract must not erase unpaid obligations. Asset types must never be silently replaced. See the [launch checklist](broken://pages/778926bacf8bfd7e0a0cce9f9bc284dec32ce34b).


---

# 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/security.md?ask=<question>&goal=<user_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.