How a claim is written, triggered and settled

A token normally states nothing about the future beyond its supply. A Claimpad token states one more thing: a condition, and what becomes claimable when that condition is met.

That statement is written at launch and is part of the token’s terms. The market prices the token knowing it. Until the condition resolves, the token trades like any other; after it resolves, eligible holders can claim what the contract holds.

The distinction Claimpad is built on is narrow and important. This is not a coin with a marketing promise attached. It is a coin with a programmed future claim, and the difference is whether anyone has to be trusted for it to pay.

A clause is the full set of terms a claim is launched with. Each one has to be decided before the token exists, because none of them can be added afterwards.

Trigger condition

The statement that has to become true.

Trigger source

The resolver that decides whether it has.

Claim asset

The token a holder receives.

Claim amount

A fixed amount, or the rule that computes it.

Eligibility rule

Which addresses may claim, measured when.

Claim window

How long the claim stays open, if limited.

Funding

Whether the claim asset is actually reserved.

Contract

The address the claim is enforced by.

A clause that omits any of these is not enforceable. A claim with no funding rule, for instance, can be stated precisely and still never pay.

A trigger is only usable if a contract can verify it without trusting the creator. That limits the set considerably, and Claimpad only offers a trigger type once a resolver for it exists.

Both are implemented by the claim contract the factory deploys, so they become available together with it. A price trigger also requires the creator to supply a Chainlink feed address, which the factory calls on chain before it will create the claim: an address that does not answer as a live aggregator is rejected and the launch reverts. Feed addresses are never hardcoded here — Chainlink documents its address list as the source of truth and says not to bake it into contracts.

A claim moves through a fixed set of states. Every one of them is read from contract state — the interface never advances a claim on its own.

1. 01Waiting for trigger

   The token is live and trading. The condition has not been satisfied, and no claim is available.

2. 02Triggered

   The resolver has reported the condition satisfied. The claim is no longer conditional, but it may not be open yet.

3. 03Claimable

   The claim is open. An eligible address can submit a claim transaction for the amount the contract holds for it.

4. 04Claimed

   A claim transaction from this address has succeeded on chain. This state is never shown on the strength of anything else.

5. 05Closed

   The claim window has passed, where the claim defined one. Claims without a window do not enter this state.

Eligibility is defined by the claim contract, not by the interface and not by holding the token as such. A clause states which addresses may claim and at what point their holding is measured — a live balance, a balance at a snapshot block, or a holding period.

Because the measurement point is part of the clause, buying a token after its snapshot may confer no claim at all. Claimpad will not tell an address it is eligible except on the basis of a contract that says so.

A claim pays from assets the claim contract actually holds. A stated claim and a funded claim are different things, and the distinction is reported rather than smoothed over: a claim can be funded, partially funded, or unfunded.

An unfunded claim is not a defect in the interface. It is a real property of the market, and hiding it would misprice the token.

The market index is read from the claim registry. Each row states the token, its condition, the claim it unlocks, and the trigger and eligibility status held on chain.

No registry is deployed on Robinhood Chain mainnet, so the index is empty. It shows an empty state rather than example markets, because a worked example rendered as a market row is indistinguishable from a real one.

These illustrate the shape of a clause. None of them has been launched, funded, or is being monitored, and they carry no prices, countdowns or balances, because none exist.

Claimpad targets Robinhood Chain mainnet and nothing else. There is no testnet or local network configuration in the application, and it does not fall back to another chain if the wallet is elsewhere — it asks you to switch.

Network

Robinhood Chain mainnet

Chain ID

4663

Currency

ETH (18 decimals)

RPC

https://rpc.mainnet.chain.robinhood.com

Explorer

https://robinhoodchain.blockscout.com

Connection is through injected wallets discovered with EIP-6963. If your wallet does not know Robinhood Chain, Claimpad offers to add it using these values, and the wallet asks you to confirm.

The contract address shown in the header comes from a single configuration file, config/contract.json, and is read from there everywhere it appears.

The address currently configured is 0x69ee026CeCB843Ea5f1f61d7ff5526a63b175CA2.

It is managed from the command line, which writes the file, commits and pushes:

npm run ca set 0x0000000000000000000000000000000000000000
npm run ca clear
npm run ca status

An address that is not a well-formed EVM address is rejected and nothing is written.

Claimpad is one deployed contract: a factory that launches a token together with its claim and is also the registry of every launch. Everything the site does is reachable from it, so a single address decides what is available:

Claimpad factory

0x414C0df7E0a2b61F9C6dbFf72e15De89A485ED48

Launching

Available

Markets and claiming

Available

What does work today is real: wallet connection, network detection and switching, and reads against Robinhood Chain mainnet. You can see the current state in the app.