> For the complete documentation index, see [llms.txt](https://docs.redacted.money/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.redacted.money/protocol/security.md).

# Security and Upgrades

Redacted's security model comes down to one rule, which is that nobody can spend what your proofs didn't authorize. Everything below applies that rule.

## No backdoors by construction

The contracts were designed so that there is nothing privileged to abuse.

* There is no sweep function, no owner override and no switch that stops a withdrawal. The Reserve's message surface is exactly the user actions, a fee-governance path and, with the node network, the node rules, and no admin message can touch users' funds. The node network's brakes can pause new deposits for everyone at once, but they never affect money going out (see [How the node network works](/node-network/node-network.md)).
* Bōheki, the DAO's 2-of-3 safety multisig, can pause deposits or switch on incident mode once, for at most about 3 days. Only the DAO can re-arm it, and it can never touch a withdrawal. See [Brakes that keep your way out open](/node-network/node-network.md#brakes-that-keep-your-way-out-open).
* The core contributors, the DAO and Bōheki can't turn away or send back anyone's money. Only the nodes can, by their own checks and votes, and a waiting deposit only ever goes back to its sender. See [How the node network works](/node-network/node-network.md).
* Spending accounts are immutable from the start. They are created without any migration admin and obey only the Reserve acting on your proofs, and nobody, including us, can change their code.
* Token holders decide the fees (the DAO until the token relaunch), but rates are hard-capped at 10% on-chain, and every change needs an on-chain notice of at least a day before it can take effect, so a change can't happen silently.
* The one power that could change these rules is a code upgrade, which waits about 3 days and is visible in advance unless all three emergency signers use the emergency lane. See [Upgrades, in the open](#upgrades-in-the-open).
* The relayer carries sealed envelopes and holds no power over them. See [Relayer](/protocol/relayer.md).

## Double-spend protection and solvency checks

Every spent note is retired by a nullifier that the contract records forever, so a note can be spent only once. On every outgoing transfer the Reserve also re-checks its own solvency, comparing its recorded obligations with its actual holdings, before it releases anything, so it can't pay out what it doesn't provably hold.

## Your side of the model

The protocol keeps your funds safe from everyone else, and two habits keep them safe from bad luck.

* Keep your backup and passphrase separate and private, because together they are your account. See [Backup and recovery](/using-redacted/backup-and-recovery.md).
* Use the official links. As with all of DeFi, the genuine frontend matters because your browser is where your keys live, so bookmark [redacted.money](https://www.redacted.money) and verify links through official channels.

## Upgrades, in the open

Every release publishes its contract identities and administration status, so what you verify is what you use. Upgrades never silently move funds, and moving to a new Reserve is always an explicit step that you take yourself.

{% hint style="info" %}
**Coming soon.** This describes how upgrades work with the node network.
{% endhint %}

The contract's code can be replaced only by the Redacted DAO (token holders after the relaunch), and always in public.

Token holders decide upgrades after the token relaunch. Until then the DAO holds their role, as a 2-of-3 group of one core contributor and two independent members, and the handover to token holders is itself a change that waits the same 3 days.

The DAO schedules an upgrade on an upgrade timelock, which holds it for about 3 days. The timelock lists every scheduled upgrade with the checksum of the new code, so anyone can see it coming, and anyone who disagrees can withdraw first, since withdrawals never wait. Until it runs, the DAO can cancel it.

All three emergency signers together can run an upgrade the DAO has already scheduled at once, and it is logged in public. At launch they are the DAO's three members, and replacing them waits the same 3 days. The emergency lane never chooses the code and can't change who controls upgrades or how long they wait. It is the one way to skip the notice, and it needs all three.

## Audits and reviews

An earlier version of the contracts was independently audited by [FailSafe](https://getfailsafe.com/redacted-smart-contract-audit). The audit was a full review of the proxy contract, the sub-wallet contracts and the proof-verification package, and it concluded that "the on-chain components align with their intended security model", with every raised issue resolved or consciously acknowledged.

The launch build adds the node network and the upgrade timelock. The internal security reviews and a second review of everything that changed since the FailSafe audit are done, and FailSafe audits the launch build before launch.

The on-chain core doesn't change without public notice. If a contract upgrade is ever proposed, it goes back to independent auditors before it reaches the chain.

The parts that change more often, such as the interface, the clients and the infrastructure, are under standing adversarial review by purpose-built security models such as FailSafe's [GlassBreak](https://getfailsafe.com) and by the latest publicly available frontier AI models, and the tooling is upgraded as the models improve. The aim is that Redacted adds no new attack vector to your life. An audit is a snapshot, and here it covers the part that cannot change without public notice.

The proof system underneath is Groth16, a widely used zk-SNARK in production. Its parameters are created by the [community ceremony](/ceremony/ceremony.md) before launch, where a single honest participant secures the setup.

## Verify it yourself

Every security claim in these docs is built to be checked with public data and open tools.

* You will be able to rebuild the contracts. The source will be published with the launch, so that the exact on-chain bytecode can be reproduced deterministically on independent systems and you can compare the hashes yourself.
* You will be able to verify the ceremony. When it closes, the full contribution transcript, circuits and final keys will be published, and anyone will be able to verify the chain end to end, down to the exact verification keys the contracts use.
* You can verify every action. Each proof is checked on-chain, in public, every time, with no privileged verifier and no off-chain judgment call.
* You can verify your own account by rebuilding it from chain data alone, in any browser. If the claim that there is no database were false, this wouldn't work.

For the privacy model, see [How privacy works](/using-redacted/privacy.md).