On-chain attestation · Internet Computer

Every number we publish arrives with its own proof.

We read Ethereum through three independent providers, check they agree, pin the result to one block, and sign it with a key no person holds. What you get back can be checked against Ethereum itself, with us switched off.

For the people who have to defend the figure afterwards: fund administrators, auditors, compliance teams, benchmark administrators.

See a proof built, step by step What we sell Certified rates

Certified rates

Realized APY, taken from a protocol's own on-chain income index. We sign the raw index and never a computed rate, so the figure is reproducible rather than reported. Fifteen series, measured daily.

Signed forecasts

Every other figure here describes the past. Five Pendle markets show what traders are paying today for a fixed return to a maturity fixed on chain, and we sign that daily. Anyone can say later what a market expected; only a signature dated then proves it. See the five markets.

Balance attestation

Signed proof of an address's ETH or ERC-20 balance at one named block: block number, block hash, timestamp. Not "as of today". As of precisely then. Generate one below.

Why an auditor can trust it without trusting us

Replay it yourself

Every bundle ships the exact RPC calls and a dependency-free Python script. Point it at your own Ethereum archive node. If the numbers match, the balance is real — no signature required.

Disagreement is surfaced, not resolved

Three providers are queried separately. If one differs, the bundle records what each returned and flags it. We never quietly pick a winner.

A key no human holds

Signing uses the Internet Computer's threshold ECDSA. The key is held by consensus across nodes; it cannot be extracted and used elsewhere — not by us either.

The code is pinned to the signature

Each attestation embeds the running module's hash, taken from the platform rather than self-reported. A signature tells you which code produced it.

What it proves, exactly

The scope is narrow on purpose, and that is what makes it hold up. An attestation states a fact about one address at one block: the balance, the block, the time, and who read it. It is evidence an auditor can re-derive, and it sits alongside your audit rather than in place of one.

Currently Ethereum mainnet only. Replay requires an archive node, because balances are read at the attested block rather than the chain head.

Code integrity & who controls it

One principal currently controls the backend canister that signs attestations and the frontend canister that serves this page, with no multi-sig or timelock in front of it yet. That is a documented fact about this deployment, and you can check it yourself:

backend module hash   0x80d8a8ff9f8c046438ebc81a877c2654137f2bf6ebbf53e096aceaddfb7eab93
controller principal  gqleh-qzmnu-avv6q-woakg-4sax2-mkvui-vsa7k-oyigl-ubdma-xqpg4-kae
last verified live    2026-09-15

Do not take that snapshot on faith. It is stale the moment we deploy again — run the same query yourself and get the current answer:

icp canister status deltarates_backend -e ic
scripts/verify-build.sh   # rebuild from source, compare the hash to the line above

What controller access does — and does not — mean, and the trigger for a timelock  ·  Full module-hash history (JSON)

Talk to us

Tell us what you have to prove, and to whom. That is usually enough for us to say whether this fits.

Get in touch contact@deltarates.com
or
ETH Native Ether · Ethereum Mainnet
Add ERC-20 tokens

Verify Proof Bundle

Verification scope: manifest integrity, attestation hash, and the ECDSA signature checked against the pinned DeltaRates canister key (expected key fingerprint: ). Optional: RPC replay against the attested chain.