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 redirect payouts — transfers always go to the signed
recipient, whether the caller is that recipient or a registered relayer; - 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.
RelayerRegistry
Section titled “RelayerRegistry”Gas-free claims introduce a second privileged actor: the relayer EOA that submits claim and pays gas. Relayers are listed in a multisig-owned RelayerRegistry that holds no funds. Only recipient == msg.sender or a listed relayer may submit; everyone else reverts. That preserves anti-sniping for random pools and allows instant revoke if a relayer key leaks. A leaked relayer key can waste gas on legitimate payouts; it cannot steal pool funds. See claim & 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 |
| Gas-free submission | Trust the relayer only to broadcast; payout address is still verifier-bound and registry-gated |
| 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,” plus an optional gas payer that cannot choose the payee, both checked by contracts that decide everything about the money.