> For the complete documentation index, see [llms.txt](https://the-heist-1.gitbook.io/the-heist-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://the-heist-1.gitbook.io/the-heist-docs/security.md). # Security The Heist is a system that holds real value, and every design decision described in these docs was made with that weight in mind. This page lays out the trust claims the protocol makes, the engineering practices behind them, and how seriously the underlying code has been scrutinized. {% hint style="warning" %} Interacting with any smart contract carries risk. Nothing on this page is a guarantee against loss, and nothing here is financial advice. Only ever risk what you can afford to. {% endhint %} ## The protocol's core promises These are the guarantees the system is built to make unconditionally — not policies that could be changed later, but properties enforced directly in the contracts: * **No hidden mint path.** LOOT can only ever be minted by the Printer, and that permission is set exactly once, at deployment. MERRY's entire 100,000-token supply is fixed in its constructor — there is no function, anywhere, that mints past it. * **No owner access to user deposits.** Administrative roles in this protocol exist to curate parameters within pre-validated ranges — things like which pools are eligible for gauge emissions — never to move funds a user has deposited. * **No pausable redemption.** [The Floor](/the-heist-docs/how-it-works/the-floor.md)'s redemption path and [Genesis](/the-heist-docs/how-it-works/genesis.md) principal withdrawal cannot be frozen by any admin key. There is no pause switch on either. * **Redemptions can never decrease the Floor.** `floorPrice` is defined so that a redemption always pays out exactly its pro-rata share — mathematically incapable of leaving remaining holders with a worse ratio than before. (Every other inflow — sell tax, Treasury share, most of the Printer's expansion proceeds — is designed to raise it and normally does; one narrow, disclosed edge case in the Printer's expansion math is documented in `DECISIONS.md`.) * **Fee rates are fixed at deploy, within validated ranges, and never adjustable upward afterward** — true of every [yield vault](/the-heist-docs/yield-vaults/overview.md) in the protocol. ## Engineering practices behind those promises * **On-chain price data only.** Every price-sensitive decision — the Printer's expansion trigger, the trading pool's tax tiers — reads the pool's own time-weighted average price. There is no external price feed anywhere in the system that could go stale, be delayed, or be fed bad data from outside the chain. * **Anti-manipulation timing built into staking and liquidity.** Newly staked MERRY activates only at the next epoch boundary, closing off same-block reward-sniping. Deposits into protocol liquidity vaults are similarly protected against a flash-loaned deposit-then-withdraw pattern trying to skim freshly-collected fees. * **Timelocked curation, not standing discretion.** Any change to the gauge-vote shortlist goes through a public proposal and a mandatory waiting period before it can take effect — and once that period passes, execution is open to anyone, not reserved for whoever proposed it. * **Battle-tested foundations.** Token and access-control logic builds on widely-used, extensively-reviewed library implementations rather than reinventing primitives like ownership transfer or reentrancy protection from scratch. * **Custom, explicit failure modes.** Every contract fails loudly and specifically — reverting with a named error describing exactly what went wrong — rather than failing silently or ambiguously. * **Extensive automated verification.** The protocol's core claims — the ones listed at the top of this page — are each backed by dedicated automated tests, including property-based (fuzz) testing that tries thousands of randomized scenarios per claim rather than a handful of hand-picked examples, plus full end-to-end scripted walkthroughs of the entire protocol lifecycle: Genesis through expansion, staking, claiming, redemption, and governance, in sequence, against real infrastructure. ## A note on scope Smart contracts are probabilistic in practice, not provably perfect: no amount of process eliminates risk entirely, and anyone telling you otherwise is selling something. What the practices above are designed to do is minimize the chance of the failure modes that have sunk other protocols in this space — hidden admin power, external oracle dependence, and under-tested edge cases — through direct construction rather than a promise to fix things later. ## Our review process Every contract in The Heist has been built from a fully locked specification, verified against an extensive automated test suite, and then subjected to a rigorous, line-by-line internal security review covering the entire system — token contracts, the peg engine, staking, protocol-owned liquidity, and every yield vault, with no exceptions carved out. That review process is not a one-time event: it runs again against every meaningful change before that change reaches real users, on an ongoing basis, for as long as the protocol exists. The code in front of you has been thoroughly, deeply reviewed. Read it, question it, and form your own judgment — the contracts are public precisely so you can. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://the-heist-1.gitbook.io/the-heist-docs/security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.