A signed statement of your reserves, delivered in days.
Kerne produces a single, cryptographically signed, point-in-time statement of your reserves that anyone can verify themselves in about three lines, without trusting you and without trusting us. One fixed fee. Nothing to embed, no DNS record, no monthly commitment, no key custody on your side: you share read-only addresses and we do the rest, with the signed statement typically back in 3 to 5 business days.
This is the same hourly attestation Kerne runs over its own reserves, re-verified in your browser on the next page. It proves the figures are authentic and fresh, not that reserves are sufficient: attestation, not an audit.
/api/por/signed$1,500 flat, one time, earned on delivery. Attestation tooling, not an audit: it proves the snapshot is real, untampered, and fresh. It does not certify solvency.
This panel reads Kerne's hourly signed attestation from the public endpoint and verifies it in your browser right now. Your delivered snapshot is this exact artifact, pointed at your addresses.
- Signed by the expected keyThe signature recovers, independently, to the named signing key (signer_matches_expected).
- Figures bound to the signatureThe numbers and timestamp rehash to the signed attestation hash, so they cannot be edited after signing (hash_matches).
- Fresh, not a relabelled old oneLast signed 23 min ago; re-signed every 1 h. Freshness is measured from the signed timestamp itself (is_fresh).
Reproduce the verdict yourself:
curl -s https://kerne.fi/api/por/signed | jq '._meta.verified' # expected: true (the signature recovered, the numbers are bound, it is fresh)
The full recovery snippets (ethers, eth_account, cast) ship inside the endpoint under _meta.verify. A delivered snapshot for your protocol carries your own signer, your own addresses, and your real figures.
What this proves. That a named key signed this snapshot, the figures are bound to that signature, and it is recent. It is attestation, not an audit: it does not certify solvency and does not bless the numbers. A protocol whose reserves were short would still verify; the backing figure is where a shortfall would show.
The standard snapshot, priced and ready
Most snapshots fit one fixed scope. If yours does, you do not need a quote or an email thread first: the price is set and you can start now. Anything larger is a short scope conversation away, not a different product.
What the fixed fee covers
- +One chain.
- +Up to three on-chain reserve addresses, read-only.
- +One optional off-chain venue equity, labeled client-reported.
- +The outstanding liability it backs, and the resulting backing ratio.
- +All three artifacts: the signed statement, the verification bundle, and the reproduction guide.
- +Delivered in 3 to 5 business days.
If the standard scope is your snapshot, pay the fixed fee and we begin. Same fee, same not-an-audit terms, no setup and no monthly commitment.
Pay the $1,500 snapshot feeYou pay in USDC on Base, straight to Kerne's own treasury address, and the transaction hash is your receipt; verify the address before you send. We confirm your scope by email after payment. Need more than one chain, more than three sources, or a faster cadence? Scope a custom snapshot.
Asserted reserves are not provable reserves
The synthetic-dollar market has been taught, repeatedly and expensively, that a backing number you cannot independently check is worth little when it matters most.
In November 2025 Stream Finance's xUSD lost about $93 million when backing that was held off-chain with an external fund manager, in no public custody, could not be accounted for. Leveraged lenders had looped the position, so the estimated contagion across the market reached about $285 million. The reported picture gave holders no independent, real-time way to see the off-chain hole before it surfaced. We wrote the full sourced scorecard of this and the other recent synthetic-dollar failures at kerne.fi/legible.
In March 2026 an attacker compromised a single off-chain signing key at Resolv, deposited about $100,000 of USDC, and minted roughly 80 million unbacked USR against it, draining approximately $24.5 million before the team could pause, according to Resolv's own post-mortem and the public analyses from Halborn and QuillAudits. The reported picture looked intact right up to the moment it did not, and holders had no independent, real-time way to tell. We wrote the full mint-path breakdown, with sources, at kerne.fi/resolv-vs-kerne.
Many issuers publish a reserves dashboard for assurance. A dashboard is assurance only while it stays reachable, and only as far as you trust the page rendering it. A signed snapshot is different in kind: the counterparty holds the proof and checks it themselves, so it does not depend on our uptime, our dashboard, or our word.
The fix in both directions is the same: backing anyone can verify cryptographically, without trusting the issuer or a page staying up. That is what a signed snapshot hands a counterparty: a statement they recover and rehash in three lines, that cannot be edited after signing and cannot quietly go stale.
Where a signed snapshot fits
There are three common ways to prove reserves to a counterparty. They are complementary, not interchangeable. For a one-counterparty, point-in-time need, a signed snapshot is typically the fastest to obtain and the lightest to act on of the three. Here is where each one fits, stated plainly.
A point-in-time, cryptographically signed reserve statement your counterparty verifies in about three lines. You share read-only addresses; there is nothing to integrate on your side and no key to custody. Typically delivered in 3 to 5 business days.
Best for: a fundraise, a listing, or partner diligence, where you need provable reserves for a specific moment, fast.
A formal examination or agreed-upon-procedures report from a licensed accounting firm, under the AICPA attestation standards or ISAE 3000 (Revised). It carries an accountant's assurance opinion, which a signed snapshot does not. It is a more involved engagement: a licensed firm scopes the work, runs its procedures, and issues a report, which generally takes weeks rather than days.
Best for: when a counterparty or regulator wants a licensed firm's formal assurance opinion.
Reserve data published on-chain as an oracle feed, such as a Chainlink Proof of Reserve feed, that consumers read from a feed address, on-chain or off. It is built for continuous, programmatic checks, for example wiring a reserve check into mint logic. Consuming it is an integration on your side, in exchange for always-on coverage that a single point-in-time snapshot does not provide.
Best for: always-on, automated on-chain enforcement across your own contracts.
If you need a licensed firm's formal opinion, or continuous on-chain enforcement, those are the right tools for that need. When you need to hand one counterparty provable reserves for a single point in time, without an integration or a weeks-long assurance engagement, the snapshot is the most self-contained option: one signed document, nothing to wire up. Many teams use it first and add the others over time.
What you get
Three artifacts, delivered together. We read the on-chain addresses that hold your backing, take any off-chain venue equity you choose to report, assemble a canonical snapshot, and sign a hash of it with a named key.
A short, written, point-in-time statement of your reserves as of a specific timestamp: the on-chain sources and balances, any off-chain venue equity (labeled client-reported), the outstanding liability it backs, and the resulting backing ratio. Signed with EIP-191 personal_sign by a named key.
The exact machine-readable bundle behind the statement: the signer address, the attestation hash, the 65-byte signature, and the canonical payload string that was hashed. These are what make the statement provable rather than asserted.
A short guide any third party follows to reproduce the proof themselves: recover the signer from the hash and the signature, rehash the canonical payload to confirm the figures and the timestamp are bound to that signature, and confirm the snapshot is recent. Three lines in ethers, eth_account, or cast.
What a recipient verifies, without trusting you
Each item is something the recipient checks directly, not something they take on faith. It is the same set of checks the live panel above ran on Kerne's own attestation.
The snapshot is signed by a named key. The recipient recovers the signer from the hash and the signature and confirms it matches the expected key.
The figures and the timestamp are inside the canonical string that was hashed and signed. Rehashing that string must equal the signed hash, so the displayed numbers are bound to the signature, not merely printed next to it. Edit a number and the hash no longer matches.
The statement's timestamp lives inside the signed payload, so a recipient can confirm the snapshot is from when it claims to be, not a relabelled old one.
See a real one before you pay
Those checks are not abstract. Here is a real signed snapshot, the exact shape the one we deliver arrives in, with the single command that recovers the signer so a recipient checks it without trusting you or us. It is pointed at Kerne's own reserves; yours is pointed at your addresses.
{
"signer": "0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e",
"attestation_hash": "0x57dbad69dc82f4b566bfb3384bdbb3f71aec8c6e9ad590320708a2d6844f5870",
"signature": "0x52c9f1dc96a0f2b0474cabee74e1bc7006df78e697d77603c61ad1b4be13cc2e6626e121613b7d68004b550cd007334b80f751a60cc8c6e04cf3cfb216667b331b",
"signed_payload_canonical": "{ ...the reserve figures, verbatim, that attestation_hash commits to... }",
"schema_version": 4,
"generated_at": "2026-06-30T23:49:47Z",
"block_heights": { "base": 48037020 }
}Captured 2026-06-30T23:49:47Z from Kerne's own hourly feed (Base Mainnet, block 48,037,020). A real read, not a mockup.
# Recover the address that signed this read from the signature alone; no private key and no trust in us are required. cast wallet verify \ --address 0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e \ 0x57dbad69dc82f4b566bfb3384bdbb3f71aec8c6e9ad590320708a2d6844f5870 \ 0x52c9f1dc96a0f2b0474cabee74e1bc7006df78e697d77603c61ad1b4be13cc2e6626e121613b7d68004b550cd007334b80f751a60cc8c6e04cf3cfb216667b331b # prints: # Validation succeeded. Address 0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e signed this message.
Prefer ethers or Python? Same three values.
import { verifyMessage, getBytes } from "ethers";
const hash = "0x57dbad69dc82f4b566bfb3384bdbb3f71aec8c6e9ad590320708a2d6844f5870";
const sig = "0x52c9f1dc96a0f2b0474cabee74e1bc7006df78e697d77603c61ad1b4be13cc2e6626e121613b7d68004b550cd007334b80f751a60cc8c6e04cf3cfb216667b331b";
const recovered = verifyMessage(getBytes(hash), sig);
// recovered === "0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e"from eth_account import Account from eth_account.messages import encode_defunct hash = "0x57dbad69dc82f4b566bfb3384bdbb3f71aec8c6e9ad590320708a2d6844f5870" sig = "0x52c9f1dc96a0f2b0474cabee74e1bc7006df78e697d77603c61ad1b4be13cc2e6626e121613b7d68004b550cd007334b80f751a60cc8c6e04cf3cfb216667b331b" rec = Account.recover_message(encode_defunct(hexstr=hash), signature=sig) # rec == "0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e"
- signer
- The address whose key signed this read. You do not take this field on trust: you recover it from the signature (the command on the right) and confirm it matches the named Kerne key.
- attestation_hash
- A sha256 fingerprint of the exact figures being attested. Change any number in the read and this hash changes, which is what makes the figures un-editable after signing.
- signature
- A 65-byte EIP-191 signature over the hash, produced by the signer's key. This is the byte that binds the figures to one specific key. It is what the recover command checks.
- signed_payload_canonical
- The exact, canonically ordered string of every attested figure, byte for byte. It is what attestation_hash is computed over; its full value is public at the endpoint.
- generated_at / block_heights
- When the read was signed and the chain block it was taken at, both carried inside the signed payload so the point in time and the freshness are provable, not asserted.
What this proves. That a named key signed these exact bytes. The command above recovers the signer today and will keep recovering it, because a signature is a permanent fact about the bytes; only freshness is point in time, and the live feed always carries the current read. It is attestation, not an audit: it does not certify solvency and does not bless the figures. Your delivered read is this exact structure, signed over your own reserve addresses, with your figures. To watch the signer recovery and the numbers binding run end to end in your browser on live data, use the free verifier at kerne.fi/verify.
What this is, stated plainly
This is attestation tooling. It proves that a specific key signed a specific reserve snapshot at a specific time, and that the published numbers match what was signed. It is not an audit of your contracts, not a guarantee that you are solvent, and not financial, legal, or accounting advice. The reserve figures come from your own on-chain addresses and any venue balances you report. We make those figures verifiable; we do not vouch for your business. That honesty is the point: a proof anyone can check is worth more than a claim nobody can. If your reserves are short, a faithful attestation will faithfully show the shortfall; it does not and cannot cure it.
To be exact about scope: this is not an independent CPA examination under the AICPA attestation standards (SSAE No. 18, AT-C sections), nor an assurance report under ISAE 3000 (Revised), and it conveys no accountant's assurance opinion. It is also not a regulatory authorization or endorsement, and it does not by itself satisfy any stablecoin authorization or licensing requirement, such as those under the EU Markets in Crypto-Assets Regulation (MiCA); consult your own counsel on your regulatory obligations. What the snapshot proves is narrower and exact: that a named key signed specific reserve figures at a specific time, and that those figures are bound to that signature.
Where the snapshot sits in the lineup
The snapshot is the natural first step. Many teams start with a single signed statement for an event and upgrade to the standing feed once they want it live for their users year round. Each tier inherits the same cryptography and the same honesty: attestation, not audit.
Want something lighter and continuous, before or alongside a signed proof? Kerne also runs peg and reserve monitoring from $99 per month: it watches your pool, reserves, and feed freshness on public data and pages you when a value moves. Monitoring tells you when something changes; a signed snapshot proves where you stand. Many teams run both.
A one-time signed, point-in-time reserve statement, the verification artifacts, and the reproduction guide. Standalone; nothing to embed or operate.
Best for: A fundraise, an exchange listing, or partner diligence, where you need provable reserves for a specific moment without committing to anything ongoing.
Everything in Tier 1, delivered as a live endpoint that re-signs every hour, plus an embeddable verification widget for your site and ongoing monitoring, freshness and uptime alerting, and maintenance.
Best for: Protocols that want always-on, continuously provable reserves their users can check at any time, not just at a single moment.
The standing feed on your own domain with a signing key you custody, across multiple chains or off-chain venues, at a faster cadence.
Best for: Larger issuers who want the endpoint under their own brand and key custody.
How payment works
The snapshot fee is $1,500, fixed, one time, earned on delivery. Payable in USDC on Base. No setup fee and no monthly commitment for the snapshot on its own.
Our guarantee. If the snapshot we deliver does not cryptographically verify against the named signing key, we refund the fee or re-run it, your call. That is the one promise attestation can make and keep. It is not a promise about the figures themselves, about solvency, or about any outcome; a faithful attestation of short reserves will faithfully show the shortfall. Typical turnaround is 3 to 5 business days.
Pay the snapshot fee in USDC on Base. The payment goes straight to Kerne's treasury address and the on-chain transaction is your receipt. Connect a wallet to pay in one click, or pay manually from any wallet or exchange and paste the transaction hash. We confirm your scope by email after payment.
Request a snapshot
Tell us what you need attested and by when. We will scope the snapshot, send a fixed quote, and offer to point a sample at your read-only addresses before you commit. One email also starts it: kerne.systems@protonmail.com.
See the live reference instance, the same stack run over Kerne's own reserves every hour, at /api/por/signed, with the public verification guide at kerne.fi/transparency.
Kerne is infrastructure and a service provider, not an auditor, custodian, or investment adviser. The signed reserve snapshot is attestation tooling: it proves the authenticity, integrity, and freshness of a reserve snapshot you provide from your own addresses and reported venues. It is not an audit, a solvency opinion, or any form of investment, legal, tax, or accounting advice. Kerne is early and not yet externally audited, disclosed at kerne.fi/dataroom; this tooling stands on cryptography you verify independently, not on our posture. The snapshot fee is $1,500 fixed, earned on delivery; tier prices above are confirmed per engagement.