Security Model
Gatoll’s security rests on a clear division: the contracts are trustless and hold the funds; the verifier is the one trusted component, and its power is deliberately narrow.
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 hand an attacker the key, and the key signs only within 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 all 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 — so rotating the protocol verifier affects only future Loots, and 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 re-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 — 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 ever say “this address is eligible,” checked by contracts that decide everything about the money.