Security
Security model and known risks
This page states what Upoch enforces, what it trusts, and what can still go wrong. It is written by the developers and has not been checked by an independent auditor. Until an independent audit is published, start with low-value workflows.
Status
The contracts implement protocol specification v0.5: the v0.4 hardening candidate, which addresses risks found in an internal review of v0.3, plus three additions the handoff requires (recovery outcome records, lookup by checkpoint hash, relayed signed submission). The full contract test suite, planted-bug checks and cross-checks between the contract and this website's policy rules pass. The same contract is deployed on Robinhood Chain testnet and mainnet, its on-chain code matching two independent builds of the source. None of this is an audit; an independent audit is planned.
Trust model
| Role | Trusted for | If compromised |
|---|---|---|
| Owner | Configuration and the final say on recovery | Total for that workflow: it can reconfigure and veto every recovery. Use a multisig. |
| Executor | Submitting checkpoints | Can submit well-formed but wrong checkpoints until a guardian pauses. Rollback fixes the record, not actions already taken. |
| Guardians (as a group) | Pausing and recovery, within the policy | A group at or above the guardian threshold can recover without the owner unless the owner cancels during the timelock or fallback delay. |
| One guardian | Emergency pause | Can pause at any time. Cannot complete a recovery alone under any valid policy, and can be removed by the other guardians. |
What the contract enforces
- Checkpoints are append-only and never modified; each links to the head at the time and is submitted by an authorised executor.
- Roles are separate: the owner is never a guardian or executor, and no address is both.
- Recovery only moves Upoch's canonical head pointer, changes executors, removes guardians and resumes. It never moves funds or calls other contracts.
- A recovery that can finish without the owner needs at least two guardians, and without owner approval at least a one-hour timelock (rules P-8 and P-9).
- A guardian minority below the threshold cannot hold the single proposal slot: the other guardians can reject its proposal.
- The contract has no admin, cannot be upgraded, makes no external calls and cannot hold ETH.
Residual risks
| Risk | Status |
|---|---|
| A guardian who keeps pausing forces one full recovery cycle before removal | Accepted; the single-guardian emergency pause is kept on purpose |
| A guardian group at or above the threshold can act without the owner | By design; the owner keeps a veto window (≥ 1 hour timelock or ≥ 1 day fallback) |
| Owner key compromise | Accepted; use a multisig owner |
| Owner unavailable with no fallback configured: workflow stays paused | Accepted; configure a fallback delay |
| Rollback reaches at most 256 steps per recovery | Deeper recovery takes several rounds; pause first |
| Block timestamps drift; recent checkpoints can be lost in a chain reorganisation | Use timelocks of hours; wait for finality |
| No proof that an agent computed its state correctly | Out of scope: execution correctness is never attested |
The complete list is in the specification.
Off-chain trust
- Clients, including this website, trust the RPC node they read from. Their consistency checks detect contradictory answers, not a node that lies consistently.
- A data check (Verified, Mismatch or Unavailable) is the observation of whoever ran it, against their copy of the data, at that time. It is never written on-chain.
- Checkpoint hashes and data URIs are public. Salt or encrypt sensitive state before hashing it.
Reporting a vulnerability
No public reporting channel has been set up for this site yet. Until one is published here, do not disclose vulnerabilities publicly; contact the project maintainers privately through a channel you already trust.
There is no bug bounty.