ThirdCheckAttestcoin binding audit

The precompile proves inclusion and continuity. Everything a contract needs before it moves money is the third check, and it is left to the developer.

The precompile says nothing about the emitter, the event, the receipt status, the order, or whether you already counted it. That gap is where cross-chain value leaks, and the value that enters Creditcoin from other chains rides exactly these proofs. ThirdCheck builds real Attestcoin proofs and uses them to release the wrong order, ships the correct checks as a drop-in library, and verifies an inbound deposit before an app credits it, so value and users cross in safely. Every proof below passes the precompile. What varies is whether the third check catches the swap.

48/53
submissions miss at least one binding check — scored across the whole field
15/16
protocol entry points exercised — a typical consumer touches 1
5/5
forged proofs the hardened escrow rejects on-chain
Shipped: the settlement escrow that passes its own auditThe bench proves the field skips the third check. This is the drop-in that does not: a cross-chain settlement escrow with all twelve binding checks, deployed on CC3, moving real value against proofs from Sepolia. Not a reference; the product.
the guarantee
12/12 binding checks enforced
5/5 bench attacks rejected·correct payment still releases
value settled, end to end
a real payment, proven through 0x0FD2, released to the seller — the same escrow that bounces every forgery below
deployed, testnet
HardenedEscrow · CC30xeC82270d…7e375ASourceSettlement · Sepolia0xD8504B26…7e88cD
ship it: the third check as a dependency

The audited logic is a Solidity library. A correct consumer is two calls, not twelve checks each team reimplements and gets wrong.

import { ThirdCheckLib } from "thirdcheck/ThirdCheckLib.sol";

// the whole third check, in two calls:
receipt = ThirdCheckLib.verifyReceipt(consumedProof, /* chain, window, proof, replay, status */);
ThirdCheckLib.bindPayment(receipt, source, orderId, seller, amount); // emitter, event, order, fields
Proven: a real order settled through the railsNot a deployment claim. An order was opened and funded on the hub, paid on Sepolia through SourceSettlement, and once the source block crossed the attestation frontier the hub ran the full third check, took the protocol fee, and paid the seller. Both transactions are public.
settled, with the fee taken
0.0009975paid to the seller
0.0000025protocol fee, 0.25% unverified
on 0.001 settled through the audited ThirdCheckLib path, by construction
operator, seller and treasury are three distinct addresses; the fee and the payout landed on-chain (testnet)
the model: any lending, RWA or trading app routes orders through the hub and settles safe by construction; the fee on safe settlement is the revenue, and a verified operator (VerifiedRegistry) settles at a lower rate
the mined path, end to end
SettlementHub · CC30x676a74fa…29B1B0
Verified inflow: value entering the chain, checked before it landsThe costliest step in cross-chain is the one that credits an inbound deposit. Roughly two billion dollars in bridge losses came from crediting a transfer without independently confirming it. Here a real deposit was locked on Sepolia naming a fresh Creditcoin beneficiary, and the consumer credited them only after proving, through the precompile and the third check, that the deposit was real, from the expected gateway, to that beneficiary for that amount, and never credited before. Both transactions are public.the full Verified Inflows story
credited on a proven deposit
0.001credited to the beneficiary
the beneficiary is a fresh address, distinct from the payer and the consumer; its on-chain balance went from zero to 0.001 (testnet)
the model: safe inbound value is how users and money enter Creditcoin; a consumer routes deposits through this inbox and credits safe by construction, and it is recorded as a verified app in the registry
the mined path, source to credit
InflowConsumer · CC30x037D8E86…fB82c0
The falsifier: one forged proof, a real app, with and without the third checkEach row is a legitimate Attestcoin proof of the wrong thing, sent to two real escrows on CC3. The left column is what a naive integration does with it: it pays out. The right is the same call once the third check is in place: it rejects, on-chain.
binding check vulnerable escrow hardened escrow
B-01Receipt status not read; a reverted payment counts
rejected
rejected
SourceTxReverted (source receipt status was not success)
B-02Emitting contract not pinned; a look-alike forges the event
rejected
NoMatchingPayment (emitting contract is not the pinned source)
B-04No replay guard on the proof itself
rejected
first release accepted; second reverted: ProofAlreadyUsed (position consumed once)
B-06Proven transaction not bound to the business object
rejected
NoMatchingPayment (the logged order does not match this one)
B-09Only the first log read; a decoy wins
rejected
NoMatchingPayment (no log binds order, recipient and amount)
POSA correct payment must still release
Source-visible defectsfound statically, no chain needed. Target shown is a public hackathon submission, cited as evidence that the catalogue describes real code.
B-11Verification via a selector the precompile does not implement
contracts/src/creditcoin/interfaces/IVerifier.sol:7 · declares verifySingle(...)
B-11Verification via a selector the precompile does not implement
contracts/src/creditcoin/interfaces/IVerifier.sol:17 · declares verifyBatch(...)
B-11A mock verifier is present in the source tree
contracts/src/creditcoin/MockPrecompile.sol:10 · contract MockPrecompile
B-11Proof verifier is swappable after deployment
contracts/src/creditcoin/Verifier.sol:59 · setVerifier(...) assigns verifierAddress
B-11Proof verifier is swappable after deployment
contracts/src/creditcoin/Lending.sol:147 · setVerifier(...) assigns verifierAddress
B-12Generator zeroes the proof on failure but still reports success
proof-pipeline/src/generateAbsenceProof.ts:125 · catch { proof = '0x'; ... success: true }
Check any contract, or scan a live GitHub repolive

This is the instrument behind the scorecard below. Paste an Attestcoin consumer, or give it any GitHub repo or .sol link and it pulls and scans the live code right here. Every submission the scorecard summarizes is public, so run the gate on any of them yourself. Same engine the CI gate runs, same verdict a pull request would get. No clone, no install, no key, nothing stored — a judge verifies every claim from this page.

press Ctrl/Cmd + Enter to run
try
The whole field, measured against the third checkThis is not an opinion. ThirdCheck read every BUIDL CTC submission and ran its own catalogue against each. Only 5 clear every applicable binding check. Rows are anonymised; each mark is what a submission evidences of the third check, not a security audit. Confirmed defects are disclosed privately to the affected teams and to team@creditcoin.org first.
48
of 53 submissions miss at least one binding check
19
go deep on the protocol; the rest are light or off-core
5
carry a confirmed binding defect (disclosed privately)
how much of the field performs each check
B-01receipt status read
28/47 fully+13
B-02emitting contract pinned
23/49 fully+18 1
B-03event signature checked
34/50 fully+11
B-04replay guard on the proof
34/48 fully+12
B-05chain identity checked
14/49 fully+28
B-06bound to the business object
14/24 fully+8
B-07payer/recipient/amount bound
19/41 fully+18
B-08block window constrained
5/18 fully+9
B-09correct log selected
8/37 fully+27
fully performs itpartial or implicitbar spans only the submissions where the check applies
every submission, ranked by third-check coverage
#project
010203040506070809
score
01
RWA-01deep
100
02
DEFI-01deep
··
100
03
RWA-02deep
96
04
DEFI-02deep
96
05
DEFI-03deep
··
95
06
AI-01deep
93
07
DEFI-04deep
93
08
DEPI-01deep
93
09
DEPI-02deep
93
10
RWA-03deep
93
11
DEFI-05deep
·
92
12
DEFI-06deep
··
91
13
DEFI-07deep
··
91
14
DEFI-08deep
89
15
DEFI-09deep
89
16
DEPI-03deep
89
17
DEFI-10deep
89
18
RWA-04deep
·
88
19
GAMI-01solid
····
83
20
DEPI-04deep
82
21
RWA-05solid
·
81
22
RWA-06solid
··
80
23
AI-02solid
···
73
24
AI-03solid
·
73
25
AI-04solid
··
71
26
RWA-07solid
71
27
DEPI-05solid
·
69
28
AI-05solid
·
69
29
AI-06solid
·
69
30
AI-07solid
·
69
31
DEFI-11solid
··
66
32
DEFI-12solid
··
62
33
RWA-08solid
··
62
34
AI-08light
··
56
35
AI-09light
····
53
36
RWA-09light
··
149
37
AI-10light
····
47
38
AI-11light
·······
47
39
DEFI-13light
···
47
40
DEFI-14light
···
47
41
RWA-10light
··
47
42
DEFI-15light
·
38
43
AI-12off-core
····
136
44
DEFI-16light
···
129
45
DEFI-17light
····
21
46
DEPI-06off-core
······
14
47
DEFI-18off-core
····
10
48
GAMI-02off-core
·········
3
49
DEFI-19off-core
·········
3
50
GAMI-03off-core
·········
3
51
INFR-01off-core
··
3
52
DEFI-20off-core
···
12
53
RWA-11off-core
!
40
Protocol surface exercisedAuditing the third check means understanding the whole precompile. ThirdCheck exercises the full surface, read-only, against live CC3. A consumer that ships one product touches one entry point.
15/16precompile entry points exercised
1touched by a typical consumer
16decoder functions understood
ChainInfo0x0000000000000000000000000000000000000fD3
find_highest_attested_before(uint64,uint64)0x981266c7live
find_lowest_attested_after(uint64,uint64)0x38bd95a7live
get_attestation_bounds(uint64,uint64)0x85600e2elive
get_attestation_genesis_height(uint64)0x0b0bbc8clive
get_attestation_height_for_digest(uint64,bytes32)0x6e7850bclive
get_chain_by_key(uint64)0x2d256bfalive
get_checkpoint_for_height(uint64,uint64)0x3c4a539elive
get_latest_attestation_height_and_hash(uint64)0x809112dalive
get_latest_checkpoint_height_and_hash(uint64)0xd773a786live
get_supported_chains()0x69e18c3clive
is_height_attested(uint64,uint64)0x9c68eccflive
BlockProver0x0000000000000000000000000000000000000FD2
calculateTxIndex((bytes32,(bytes32,bool)[]))0x44f85f1clive
verify(uint64,uint64,bytes,(bytes32,(bytes32,bool)[]),(bytes32,bytes32[]))0x7cc4e258probed
verify(uint64,uint64[],bytes[],(bytes32,(bytes32,bool)[])[],(bytes32,bytes32[]))0x1b5f6f88probed
verifyAndEmit(uint64,uint64,bytes,(bytes32,(bytes32,bool)[]),(bytes32,bytes32[]))0x02f4d167on-chain
verifyAndEmit(uint64,uint64[],bytes[],(bytes32,(bytes32,bool)[])[],(bytes32,bytes32[]))0x4da3b895enumerated
exercised: live call or on-chain evidenceprobed: reached and input-validatedenumerated: needs a funded batch run
catalogue coverage
B-01Receipt status not read; a reverted payment countsdynamic
B-02Emitting contract not pinned; a look-alike forges the eventdynamic
B-03Event signature not checkeddocumented
B-04No replay guard on the proof itselfdynamic
B-05Chain identity of the proof not checkeddocumented
B-06Proven transaction not bound to the business objectdynamic
B-07Fields not bound: payer, recipient, amountdocumented
B-08Block window not constraineddocumented
B-09Only the first log read; a decoy winsdynamic
B-10Acts before the attestation frontier advancesstatic
B-11Verifier swappable, or addressed by a non-existent selectorstatic
B-12Off-chain failure treated as a negative observationstatic