Skip to content

50% OFF your first payment. Limited time!

Claim your 50% Discount

Arc-native APIs

Settlement proofs

Arc finalises on commit. The commit certificate is the evidence, and this endpoint makes it retrievable by transaction hash and checkable offline.

Why it exists

A receipt says a node believes a transaction executed. A commit certificate says two thirds of the validator set signed the block that contains it. On a chain whose customers are clearing houses and card networks, the second is the artefact that ends an audit question, and no other Arc provider serves it.

Fetch

http
GET /v1/$KEY/proof/0x91c4…7fe

{
  "txHash": "0x91c4…7fe",
  "height": 5185952,
  "round": 0,
  "blockHash": "0x4f21…a0c",
  "signatures": [{ "validator": "0x…", "sig": "0x…" }],
  "quorum": "9/11 voting power",
  "receipt": { "status": "0x1", "gasUsed": "0x5208" }
}

Certificates are cached at the head and backfilled to genesis, so a proof for an old transaction costs the same as a proof for one from this minute.

Verify offline

The verifier takes the JSON and checks it without touching the network, which means an auditor can run it inside an air-gapped environment and does not have to trust us or the endpoint that served the proof.

bash
npx @arcrpc/verify proof.json

# validator set matches the height           ok
# signature quorum 9/11                      ok
# block hash matches the signed payload      ok
# receipt is included in the signed block     ok

What teams do with it

  • Attach a proof to every settlement record, so month-end reconciliation has evidence per line.
  • Release goods or credit on the proof rather than on a confirmation count, since Arc cannot reorg.
  • Hand the proof and the verifier to an external auditor instead of granting them RPC access.

The underlying method is arc_getCertificate, documented on the Arc namespace page, if you would rather query by height yourself.