Security model and limits
What Tidemark protects against, what it assumes, and where it can be fooled.
What you trust
| Component | Assumption | Mitigation |
|---|---|---|
| RPC | Serves the real chain | finalized reads, a second --rpc cross-check, and the ledger itself hashing deployed bytes |
| Rules | Catch the change you care about | versioned, deterministic, tested against patched backdoors; heuristics, not proofs |
| Reviewers | Act independently | each co-signer re-runs the review; quorum is only as independent as the people |
| Registry authority | Adds honest reviewers | reviewer changes bump config_version and late approvals are shown |
| Ledger program | Its code is what was reviewed | clients print its upgrade authority and warn on redeploys; multisig then freeze |
| AI judge | Nothing | advisory only, can only raise risk, never part of a hash |
Hostile binaries
Programs under review are attacker-controlled. Inputs over 16 MiB are refused, the diff has a deadline, scans have caps, and when a limit is hit the report says so with TM-PARTIAL instead of passing quietly. The ELF and ledger parsers are model-checked with Kani.
Known limits
- Keys computed at run time or read from an account are not constants and are not found.
- Malicious logic added inside an existing handler, or a reused CPI call site, may only show in the hunks.
- Merged error returns after a compiler change can raise a false TM-CHECK-GONE.
- A same-source rebuild from SBPF v2 to v3 can raise a false TM-CHECK-GONE.
- Non-Anchor programs get the bytecode rules but no per-handler check counts.
- On-chain ELF hashing costs about 0.5 compute units per byte, so programs over about 2.7 MB cannot be attested.
Found something else? Open an issue.