Smart Contracts
The contract layer is the source of truth for funds. It is intentionally small: one factory, three pool implementations, and a shared base.
Factory & minimal-proxy clones
Section titled “Factory & minimal-proxy clones”PoolFactory deploys one pool per Loot using the OpenZeppelin Clones minimal-proxy pattern. Three implementation templates, one per asset type, are deployed once; each new Loot is a lightweight proxy that delegates to the matching template and is then initialized with the campaign configuration.
Per-Loot deployment therefore costs a fraction of deploying a full contract, which makes many small campaigns economical. The factory also snapshots the current verifier address into each pool at creation time, so a pool’s authorizer is fixed for its lifetime even if the protocol later rotates the verifier.
Pool implementations
Section titled “Pool implementations”| Implementation | Holds | Deposit | Transfer |
|---|---|---|---|
| ETHPool | Native token | msg.value | native transfer |
| ERC20Pool | One ERC-20 | approve + transferFrom | safeTransfer |
| ERC721Pool | Specific NFTs | batch safeTransferFrom | per-token transfer |
All three extend a shared PoolBase, which inherits a reentrancy guard and holds the common configuration, contribution ledger, status logic, and claim/reclaim flow.
Mainnet deployments
Section titled “Mainnet deployments”The current mainnet deployments are listed below. Each network has its own PoolFactory, implementation contracts, verifier, and multisig owner.
| Component | Ethereum mainnet | BNB Smart Chain mainnet |
|---|---|---|
| PoolFactory | 0x15223285C92f9bD1aFAfAB7e9B65c36B038e175D | 0x8b86CCc413875e80771A4cb156Df0e06268da49b |
| ETHPool | 0x56D28FF25e111d93eb536D24E70461e1c2EF9F4C | 0x4BB8d502a184Ab993c87116c8f087D5e46a2Ed29 |
| ERC20Pool | 0xf94DaB5F8dE94DEC45B10ED81b05438823ca3c17 | 0x56D28FF25e111d93eb536D24E70461e1c2EF9F4C |
| ERC721Pool | 0x8b86CCc413875e80771A4cb156Df0e06268da49b | 0xf94DaB5F8dE94DEC45B10ED81b05438823ca3c17 |
| Verifier | 0x043B5B25Bd5a44EDb319910387F1C741F1eb4DDe | 0x043B5B25Bd5a44EDb319910387F1C741F1eb4DDe |
| Multisig owner | 0x50D08f2294ECD8410663A75e7D2D1AEaCd935Bc3 | 0x50D08f2294ECD8410663A75e7D2D1AEaCd935Bc3 |
Deployment metadata:
| Network | Deployer | Multisig threshold | Deployment time |
|---|---|---|---|
| Ethereum mainnet | 0x043B5B25Bd5a44EDb319910387F1C741F1eb4DDe | 1 | 2026-06-01 07:42:14 UTC |
| BNB Smart Chain mainnet | 0x043B5B25Bd5a44EDb319910387F1C741F1eb4DDe | 1 | 2026-06-01 06:36:30 UTC |
Configuration & state
Section titled “Configuration & state”At creation, the pool snapshots an immutable config: creator, verifier, token address, asset type, play style, start/end time, max claimers, and whether outside contribution is allowed. Alongside it, the pool tracks state: remaining balance, totals contributed and claimed, and contributor and claimer counts.
Status machine
Section titled “Status machine”Status is derived, not stored:
- Pending until the start time passes and the pool has at least one contribution.
- Active once both conditions hold; claiming is open.
- Ended when the end time passes, all seats are claimed, or the balance reaches zero.
Contributions are accepted only while Pending. This keeps a live campaign’s reward pool fixed, so participants always claim against a known balance.
Contribution ledger
Section titled “Contribution ledger”Each contributor’s amount, and for ERC-721 the exact token IDs, is recorded on-chain. The first deposit from an address increments the contributor count. This ledger is what makes reclaim fair: no one can recover more than they put in.
Events & transparency
Section titled “Events & transparency”Every meaningful action emits an event: pool creation, contributions, claims, reclaims, the pool ending, and verifier/implementation/governance changes. The indexer consumes these events to build read models, and anyone can reconstruct a Loot’s full history from chain logs. Transparency is a property of the system, not a feature bolted on top.