Finality you can check, not finality you trust.
Arc finalises every block with a BFT commit certificate: the round, the block hash and the validator signatures. Give us a transaction hash and we return the receipt, that certificate, and a verifier that runs offline. It is the artefact an audit or reconciliation team actually needs, and nobody else productises it.
POSTrpc.arcrpc.com/v1/{API_KEY}
request
{
"jsonrpc": "2.0",
"id": 1,
"method": "arcrpc_getSettlementProof",
"params": ["0x9f2c...a41e"]
}responseverifiable offline
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tx_hash": "0x9f2c...a41e",
"status": "success",
"block_number": 4210887,
"block_hash": "0x3b8e...77d2",
"certificate": {
"round": 0,
"signatures": 12,
"validator_set": "0x51c0...e9a3"
}
}
}A settlement chain whose settlement nobody proves.
Arc’s founding validators include BlackRock, DTCC, Visa, Mastercard. Its pitch is deterministic settlement. Yet the one primitive that makes settlement machine-checkable, arc_getCertificate, is undocumented by every officially listed provider. A “confirmed” flag from an API is a claim. A certificate signed by the validator set is evidence.
From transaction hash to signed evidence.
Four steps, all against Arc's own data. The last one runs on your machine.
- Input
Transaction hash
Any transaction on mainnet or testnet, from genesis to the block that just committed.
- Inclusion
Receipt and block
The receipt, the block it was included in, and the block hash that commits to it.
- Finality
Commit certificate
The BFT certificate for that height from arc_getCertificate: round, block hash, validator signatures. Cached, so historical proofs are instant.
- Verification
Checked offline
The verifier confirms inclusion and that the block hash carries a quorum of signatures from the published validator set. No network, no key, no trust in us.
One call to fetch. One command to verify.
Proofs are plain JSON. Store them next to the payment they prove, hand them to an auditor, or verify them in CI.
Fetch the proof
arcrpc_getSettlementProof by transaction hash, on every plan.
Verify it anywhere
The verifier is open source and needs only the proof file and the validator set.
Or export a range
Every certificate for a block range, signed and delivered for an audit file.
Timed from key creation to the first message on the wire.
curl https://rpc.arcrpc.com/v1/YOUR_KEY \ -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1, "method":"arcrpc_getSettlementProof", "params":["0x9f2c...a41e"]}' > proof.jsonWhere a certificate beats a confirmation.
Payment operations
Attach the proof to the payment record at the moment of settlement. A dispute becomes a file, not an investigation.
Audit and reconciliation
Hand auditors evidence they can verify independently, for any range, without access to your systems or ours.
Cross-system settlement
Release goods, credit an account or trigger a CCTP leg on proof of finality rather than on a count of blocks.
The rest of the platform
Prove every settlement.
Settlement proofs are on every plan, including Pro. Correctness is never a paid upgrade.
Common questions
Settlement you can prove: every block carries a BFT commit certificate signed by the validator set, so a payment can be shown final offline. Webhooks that act on the first block, because the finalized tag is the latest block. Payment references joined to transfers through Arc's Memo contract. Compliance events from the USDC blocklist and the protocol Denylist. And no public mempool, so nobody can watch or front-run a transaction before it lands.
The BFT commit certificate for the block a transaction landed in: the round, the block hash and the validator signatures, from arc_getCertificate. Given a transaction hash we return the receipt, the certificate and a verifier you can run offline, so finality is something you check rather than something you trust.