Quests

Gully Quests is the chain's built-in quest system: the Gully answer to Layer3 and TaskOn, with one difference that matters. A quest is not checked by a server that looks at your wallet; it is checked by a contract that reads the chain's own state when you call complete(questId, proof). The completion is written on chain as an attestation (QuestCompleted(questId, account, block, evidence, reward)), and the reward is paid from an escrowed pool in the same transaction.

Source: gully-labs/gully-quests (Foundry, solc 0.8.28, OpenZeppelin 5.6.1).

#How a quest works

1. Create. Anyone calls createQuest with a title, a metadata URI, a start and end, the maximum number of completions, the reward asset (ETH, glUSD, USDC.e or WETH) and amount per completion, a verifier module with its parameters, and an optional reputation gate.
2. Fund. The creator (or any sponsor) funds the pool with fund (ETH) or fundERC20. 5% of every deposit goes to the Gully treasury at that moment; the other 95% is the quest's pool, held by QuestEscrow.
3. Do it. The user does the thing on GullyChain: claims a .gully name, buys a launchpad token, swaps, bridges, scores in the arcade, refers a friend, holds a token.
4. Verify. The app calls canComplete(questId, account, proof) (a read) and shows the exact proof the contract will check: the verifier, the decoded parameters, the proof bytes and the evidence the verifier returns (a name node, a token address, a transaction hash).
5. Claim. complete(questId, proof) from the user's own account (an EOA or a passkey smart account). The registry records the completion and pays the reward. One completion per account per quest.

Seed quests on the testnet (rewards are testnet ETH with no value):

#Verifiers

Where the chain keeps state, the verifier reads it and nobody has to be trusted. Where an action only exists as an event (router swaps, launchpad sells) or on another chain (bridge deposits), the Gully attest server derives an EIP-712 attestation from the indexer and the chain's blocks, and the contract still enforces the quest id, the account, the action kind (bound to the quest's parameters), the minimum value, the expiry and the attester address. The attester is a key that holds no funds and can be rotated per verifier.

#Fee model

• 5% of every deposit to the treasury, taken when the pool is funded. Nothing on completions, claims, refunds or creation.
• Funding 0.0005 ETH gives a 0.000475 ETH pool: four completions at 0.0001 ETH. The creator console shows the fee, the net pool and the completions covered before you sign.
• The fee is owner-settable up to 10% for future deposits; pools already funded are never touched.

#Security and trust

• No stuck funds. pool - paid is always exactly what the escrow holds for a quest. Creators can pause, cancel (immediate refund of what is left) and withdraw unclaimed rewards after the end; if a creator disappears, anyone can trigger that refund 180 days after the end, and it still goes to the creator. A reward whose ETH transfer fails is credited for a pull claim instead of blocking the quest.
• The platform cannot touch a pool. The owner can allow verifiers and reward assets, set the fee and treasury, pause new activity (never refunds) and cancel an abusive quest (the refund goes to its creator). There is no sweep and no upgrade; the escrow has no owner at all.
• Sybil resistance. One completion per account per quest. A quest can require a verified .gully name and a minimum account age (an attested first-seen block that can only ever be lowered). Holding quests use a snapshot, so a flash-loaned balance cannot pass.
• Large pools. Merkle mode records completions on chain and lets the creator post a reward tree after the end; claims are guaranteed for 30 days before the creator can withdraw the rest.

Quest windows are timestamps, not block numbers, because block.number on GullyChain is the parent chain's block number (see Network reference); the completion attestation records that parent block number, and the indexer adds the GullyChain block and time.

#For builders

Verifiers implement one interface, IQuestVerifier { verify(questId, account, params, proof) view returns (ok, evidence); validateParams(params); kind() }, and the owner allow-lists them, so any Gully contract (a game, a market, a DAO) can get its own quest type. Useful reads: quest(id), questParams(id), available(id), completedAt(id, account), canComplete(id, account, proof). Indexer routes: /quests, /quests/:id, /quests/:id/completions, /accounts/:a/quests, /quests/stats. To get a verifier allow-listed, write to [email protected].