Verified Inflowspart of ThirdCheck the full bench
value crosses in only when the crossing is safe

The check on money coming in. An inbound deposit is proven before an app credits it, independent of any bridge.

Crediting an inbound cross-chain transfer is the costliest step in the whole space. Roughly two billion dollars in bridge losses came from crediting a message without independently confirming it. Verified Inflows applies the third check to that exact step: the deposit is real, from the expected gateway, to that beneficiary for that amount, on the right chain, and never credited before, all proven through the Attestcoin precompile with no bridge and no relayer trusted.

Proven: a real deposit, checked then credited
credited on a proven deposit
0.001credited to the beneficiary
0 → 0.001a fresh address, distinct from payer and consumer
no bridge and no relayer in the trust path; the credit waited on the proof (testnet)
the mined path, source to credit
InflowConsumer · CC30x037D8E86…fB82c0
What the inbox proves before it creditsThe precompile at 0x0FD2 proves inclusion and continuity, then stops. Everything below is the third check, run by the consumer, in two library calls.
statusThe source transaction actually succeeded. The precompile does not check this.
emitterIt came from the expected gateway, not a look-alike contract.
eventIt is the Deposited event, matched by signature, not another log.
depositIt is bound to this deposit id, so one proof credits one deposit.
chainIt is on the right source chain, pinned at deploy, never the caller's claim.
windowIt sits inside a fresh block window, so a stale block cannot be replayed.
replayThe proven position is consumed once; the deposit is credited at most once.
logselThe correct log is selected among many; a decoy that fails a later check is skipped.

In the library this is verifyReceipt plus bindDeposit, a second predicate over the same verified receipt, so the check generalises past payments without loosening a single guarantee. ThirdCheck exercises 15 of 16 protocol entry points, where a typical consumer touches 1.

Why this is the growth edge, not just a guard

Value and users cross into Creditcoin from larger chains only when the crossing is safe. Every bridge, ramp and cross-chain deposit is a moment where a consumer can be credited off a lie, and that fear is what keeps liquidity out. Verified Inflows removes it at the exact step where the loss happens. Any wallet, ramp, lending or RWA app routes its inbound deposits through the inbox and credits safe by construction, and a verified operator settles at a lower rate. Safe inflow is how the ecosystem pulls in users and value it otherwise cannot.

A reference adopter: a cross-chain credit line on the libraryNot a third-party integration. A second app, built by the same team, to show the library is something products build on and not only the ThirdCheck contracts themselves. A user locks collateral on Sepolia; once the third check proves the inbound deposit, the app opens a credit line and the user draws against it, all on testnet.
the line a real user opened
0.001collateral verified
0.0005credit line · 50% LTV
0.0003drawn · 0.0002 still available
the credit line and the draw depend on the same verifyReceipt + bindDeposit, no check reimplemented
the mined path, collateral to draw
CreditLineApp · CC30xE6049333…0191f7
Deployed on testnet
SourceGatewayEthereum Sepolia0x87962866…D5886EInflowConsumerCreditcoin CC30x037D8E86…fB82c0CreditLineAppCreditcoin CC30xE6049333…0191f7