← Protocols
Layer3
01Description

Quest aggregator and onchain credential layer. Mints CUBEs (ERC-721 credentials) that attest to multi-chain, multi-dapp quest completions.

02Best for
  • 01embedded quest experiences via Quest API
  • 02CUBE credential minting for completions
  • 03loyalty + referral programs across L2s
  • 04onchain reward escrows (Factory.sol/Escrow.sol)
  • 05cross-app reputation
03Install
  • forge install layer3xyz/cubes
04Environment variables
VariableScopeDescription
LAYER3_QUEST_API_KEYServerPartner Quest API key (issued via Layer3 partnership program).
NEXT_PUBLIC_LAYER3_CHAIN_IDClientChain ID where CUBE.sol is deployed (e.g. 8453 Base, 10 Optimism).
05Prompt snippet
Use Layer3 to embed quests and mint CUBEs. The Quest API is gated and partner-only — once approved, fetch `GET /quests` and submit completion via `POST /quests/{id}/complete` with the user's signed message. To mint a CUBE on a custom quest, deploy via the `CUBE.sol` ERC-721 contract (`mintCubes(CubeData[], signatures[])`) backed by a signer registered in the Factory; rewards flow through `Escrow.sol`. Onchain attestation is final — design your verifier and signer custody with that in mind.
06Gotchas
  • Quest API is invite-only; self-serve is limited to the in-product builder. Plan for partnership lead time.
  • CUBEs are non-transferable ERC-721s — burning/revoking requires admin keys, plan a key-rotation policy.
  • Quest completion proofs are EIP-712-signed by Layer3 signers; client tampering with the signed payload invalidates the mint.
  • US/sanctioned-region IP blocking applies to layer3.xyz frontend; the API itself doesn't enforce, but TOS does.
  • Onchain mint costs gas on Base/Optimism per CUBE — for high-volume campaigns, batch via `mintCubes` plural to amortize.
  • Cooldown windows on repeat-quest completion are enforced server-side; your indexer should not assume a 1:1 wallet-to-CUBE mapping.
07Alternatives