Security Model
Gatoll’s security rests on a clear division: the contracts are trustless and hold the funds, while the verifier is the one trusted component, with deliberately narrow power.
Verifier key custody
Section titled “Verifier key custody”The verifier authorizes claims by signing EIP-712 vouchers. Its signing key is held per chain in a hardware-backed secret, isolated from application code and never exposed in logs or configuration. A compromise of the wider system does not automatically give an attacker the key, and the key signs only the narrow ClaimAuth structure the contract understands.
Governance & key rotation
Section titled “Governance & key rotation”The verifier’s on-chain address, the pool implementations, and the governance wallet itself are changed only through a multisig. No single operator can swap the verifier, repoint an implementation, or seize control. Crucially, each pool snapshots its verifier at creation and never changes it. Rotating the protocol verifier affects only future Loots; an existing Loot’s authorizer is fixed for its lifetime.
What the verifier cannot do
Section titled “What the verifier cannot do”Even a fully misbehaving verifier is bounded by the contract, which independently checks every claim:
- it cannot move funds — it holds none and has no withdrawal path;
- it cannot pay the wrong pool — the voucher is domain-bound to one pool address;
- it cannot pay someone else —
recipientmust equal the caller; - it cannot double-pay — single-use nonces and one-claim-per-wallet are enforced on-chain;
- it cannot mint value the pool lacks, because transfers are capped by the real balance.
The verifier decides eligibility; the contract decides settlement.
On-chain safety
Section titled “On-chain safety”- Replay protection. Domain +
poolAddress,recipient, a burned single-usenonce, and a shortdeadlinetogether make every voucher one-shot. See claim & settlement. - Reentrancy guards. Claim and reclaim are protected against reentrancy.
- Immutable config. A pool’s creator, verifier, asset, play style, window, and seats are snapshotted at creation and cannot be edited afterward.
- Bounded reclaim. Reclaim reads the on-chain ledger, so no contributor can recover more than they contributed. See reclaim.
Trust assumptions
Section titled “Trust assumptions”| Layer | Assumption |
|---|---|
| Pool funds | Trustless: escrowed and released by code |
| Allocation & settlement | Trustless: computed and enforced on-chain |
| Claim eligibility | Trust the verifier to evaluate Gates honestly; its key is hardware-backed and multisig-governed |
| Campaign data | Read from the indexer; always reconcilable against chain events |
This is the smallest trusted surface the design allows: one oracle that can only say “this address is eligible,” checked by contracts that decide everything about the money.