Claim

A claim's core function is to provide cryptographically verifiable proof of an entitlement. This is typically achieved through digital signatures, zero-knowledge proofs, or on-chain state. The proof is independently verifiable by any network participant without relying on a central authority.

• Digital Signatures: Prove ownership of a private key associated with an asset.
• Zero-Knowledge Proofs: Prove a claim is valid without revealing underlying data (e.g., proving age > 18).
• On-Chain State: A smart contract's storage acts as the canonical source of truth for claims (e.g., ERC-721 ownerOf function).

Claims are validated by the consensus rules of the underlying blockchain or protocol, not by a central issuer. This eliminates counterparty risk and the need for trusted intermediaries. The validity of a claim is objective and based solely on cryptographic verification and protocol state.

• No Central Vault: Assets are not held by a custodian; ownership is proven via the claim itself.
• Protocol as Arbiter: Rules are enforced by code (smart contracts) and network consensus.
• Permissionless Verification: Anyone can run a node to verify the entire history and state of claims.

Claims are programmable units that can be integrated, combined, and used as inputs for other smart contracts and decentralized applications (dApps). This enables complex financial instruments and automated workflows.

• Financial Legos: Claims to tokens can be used as collateral in lending protocols (e.g., Aave, Compound).
• Conditional Logic: Claims can be vested, streamed, or released based on time or events.
• Cross-Protocol: A claim from one protocol (e.g., an LP position) can generate a derivative claim in another (e.g., a collateralized debt position).

Widely adopted token standards (like ERC-20, ERC-721, and ERC-1155) create consistent interfaces for claims. These standards define how to query ownership, transfer rights, and approve third-party interactions, ensuring interoperability across the ecosystem.

• ERC-20: Standard interface for fungible token claims.
• ERC-721: Standard interface for non-fungible token (NFT) claims, providing a unique tokenId.
• ERC-1155: Multi-token standard allowing for both fungible and non-fungible claims within a single contract.

Claims can have temporal or conditional validity. They may be designed to expire, be revoked by the issuer (in certain permissioned models), or become invalid if specific conditions are not met. This is crucial for subscriptions, credentials, and time-bound access rights.

• Expiring Claims: Used for software licenses, API keys, or event tickets.
• Soulbound Tokens (SBTs): Non-transferable claims representing identity or achievements.
• Conditional Claims: A claim to rewards may only be valid if a user completes specific tasks.

A critical distinction exists between a claim representation and the underlying asset. Wrapped tokens (e.g., wBTC) are claims on a custodied Bitcoin. Layer 2 solutions issue claims representing assets on the mainnet. The security of the claim depends on the verifiability of the bridge or custodian.

• Bridged Assets: Claims on another chain's assets (e.g., USDC on Arbitrum is a claim on Ethereum-based USDC).
• Synthetic Assets: Claims that track the price of an off-chain asset (e.g., synthetic gold).
• Custody Risk: The claim is only as strong as the mechanism backing it.

The most common usage, where users prove eligibility to receive free tokens. This involves:

• Connecting a wallet to a claim portal.
• The portal verifies on-chain activity (e.g., snapshot) or off-chain criteria.
• Users sign a transaction to claim the tokens, moving them from a distribution contract to their wallet.
• Examples: Uniswap's UNI, Arbitrum's ARB, and Optimism's OP airdrops.

Claims manage the release of locked tokens over time.

• Tokens are allocated to a vesting contract with a predefined schedule (e.g., linear over 4 years).
• At each claim period (e.g., monthly, quarterly), the beneficiary can execute a claim transaction to release the unlocked portion.
• This is standard for team, investor, and advisor allocations to align incentives.

Users claim accrued rewards for providing services to a protocol.

• Liquidity providers (LPs) earn reward tokens for depositing assets into pools.
• Rewards accrue in real-time but are not automatically distributed.
• A manual claim transaction is required to harvest the rewards, updating the user's balance. This design reduces gas costs for the protocol.

Two primary technical standards for verifying claims.

• Claimable Contracts: Hold tokens for each eligible address; a simple call transfers them. Efficient for small, known lists.
• Merkle Proofs: Use a Merkle root stored on-chain. Users submit a proof (a small data blob) that cryptographically verifies their inclusion in a large, off-chain eligibility list. This is gas-efficient for massive distributions (e.g., to millions of addresses).

Standards that improve the claim user experience.

• ERC-2612 (Permit): Allows users to sign a message approving token transfer off-chain, then a relayer can submit the claim transaction, paying the gas fee. This enables gasless claims.
• EIP-712: Provides a standard for structured data signing, making off-chain signatures for claims more secure and readable by wallets.

Key risks and best practices in claim mechanisms.

• Phishing: Fake claim websites are a major threat. Always verify contract addresses.
• Expiration: Claims often have deadlines; unclaimed tokens may be forfeited or redistributed.
• Reentrancy: Claim functions must be secured against reentrancy attacks when transferring tokens.
• Front-running: In some designs, public claim transactions can be front-run; using merkle proofs with msg.sender mitigates this.

A cryptographic method for proving the validity of a claim without revealing the claim data itself. This enables:

• Privacy: Prove you own an asset or credential without exposing its details.
• Scalability: Batch-verify many claims off-chain with a single on-chain proof.
• Compliance: Demonstrate regulatory adherence (e.g., KYC) while preserving user anonymity.

Critical mechanisms to maintain the integrity of a claims system. A revoked or expired claim must be instantly recognized as invalid to prevent unauthorized access.

• Revocation Registries: Maintain a cryptographically verifiable list of revoked credential IDs.
• Time-Based Expiry: Claims can have a built-in validity period, after which they must be re-issued.
• Status List 2021: A W3C standard for a privacy-preserving, space-efficient revocation status list.

Preventing a single entity from creating multiple fraudulent identities (Sybils) to game a system. Claims are a primary tool for Sybil resistance when tied to unique, costly-to-forge identifiers. Methods include:

• Proof-of-Personhood: Biometric or government ID-based claims.
• Proof-of-Uniqueness: Cryptographic protocols that ensure one-human-one-identity.
• Staked Identity: Requiring a financial stake that would be lost if the identity is fraudulent.

The security of a claim depends on the trustworthiness of its issuer. Systems must verify issuer authenticity and the integrity of the attestation. Key considerations:

• Issuer DID: The claim must be verifiably signed by a known issuer's decentralized identifier.
• Trust Registries: On-chain lists of accredited or trusted issuers for specific claim types.
• On-Chain vs. Off-Chain: Claims can be issued on-chain (as verifiable by smart contracts) or off-chain (as signed JSON objects), each with different trust and privacy implications.

The process of gradually releasing locked tokens to their beneficiaries according to a predefined schedule. A claim is the action taken by the beneficiary to withdraw the portion of tokens that have vested (become unlocked) at a given point in time.

• Smart Contract Role: Holds the total allocation and enforces the release schedule (e.g., linear over 4 years).
• Claim Trigger: The beneficiary must send a transaction to the vesting contract to claim their available balance.
• Key Feature: Prevents immediate sell pressure by team members and investors post-token generation event (TGE).

A cryptographic proof used to efficiently and verifiably prove membership of a piece of data (like a wallet's airdrop allocation) in a large set without revealing the entire set. This is the core technical mechanism behind many gas-efficient claim processes.

• How it Works: A Merkle tree hashes all eligible addresses and amounts. The Merkle proof is a small set of hashes that proves a specific leaf (your data) belongs to the tree's root hash stored on-chain.
• Benefit: The contract only needs to store a single root hash (32 bytes) instead of a massive list of addresses, saving significant gas costs.
• Use Case: Used in airdrops by Uniswap, Optimism, and Arbitrum.

The specific evidence submitted in a transaction to demonstrate eligibility for an asset. This is often a digital signature or a Merkle proof. The on-chain contract logic validates this proof before releasing the assets to the claimant.

• Types:
  • Merkle Proof: As described above.
  • Signature (ECDSA): The distributor signs a message containing eligibility details; the user submits this signature.
• Security: The claim is permissionless and trustless; the contract's immutable logic is the sole arbiter.
• Finality: A successful claim transaction permanently burns the proof, preventing double-claiming.

A broad category encompassing staking rewards, liquidity provider (LP) fees, and other incentive mechanisms where accrued earnings must be actively claimed by the participant. Unlike an automatic transfer, this pull-based model gives users control over the timing and gas cost of the transaction.

• Pull vs. Push: Claiming is a pull mechanism (user initiates). Automatic distribution is a push (contract initiates, often more gas-intensive for the distributor).
• Accounting: Contracts track a cumulative rewards-per-share metric and a user's last checkpoint; the claimable amount is the difference.
• Examples: Claiming COMP rewards from Compound, or CRV rewards from a Curve gauge.

A specific state variable within a smart contract that tracks the amount of an asset a given address is entitled to withdraw at a specific block. This is the on-chain representation of an unclaimed asset.

• On-Chain State: A mapping such as mapping(address => uint256) public claimableBalance;.
• Interaction: Increases when rewards vest or an airdrop is configured. Decreases to zero when a user executes a claim transaction.
• View Function: Users typically call a checkClaimableAmount(address user) function to query this balance before claiming.