The Light Client
How STRATO checks Ethereum without trusting anyone about it.
The bridge promises that nobody vouches for your deposit — a contract checks it. This is that contract. STRATO runs a real Ethereum light client that follows Ethereum's own validators and can prove, on-chain, that a specific deposit happened in a block Ethereum finalized. No operator attests, no multisig signs off; the settlement chain re-checks Ethereum's consensus itself.
Following Ethereum's validators
Ethereum finalizes blocks with a sync committee — 512 validators, sampled afresh each period, who sign each header Ethereum produces during that period. A period is a fixed span, roughly 27 hours. If you know the committee for a period and you see enough of them sign a header, you know Ethereum finalized it. The light client's whole job is to always know the current committee.
It learns the first one from a single trusted starting point and everything after that trustlessly:
bootstrapinstalls one period's committee — the one time an operator is trusted, to plant a root of trust. It happens once.advanceCommitteecarries the chain forward from there, and anyone can call it. It takes one of Ethereum's own light-client updates and checks that the current committee signed a header which itself commits to the next committee — so each period is proven by the period before it, back to the bootstrap. A malformed update can't forge a committee; it can only fail to verify. At least two-thirds of the 512 must have signed for the update to count.
Because advancing is permissionless and self-checking, keeping STRATO's view of Ethereum current is not a privileged operator function — it is maintenance anyone can perform, and the exchange runs a daemon that simply does it on schedule.
For the curious
Committee signatures are BLS aggregates on the BLS12-381 curve. Verifying one on-chain means reconstructing the aggregate public key of exactly the validators who signed — and doing it inside STRATO's gas cap. The trick: when most of the committee signs, the contract starts from the pre-stored aggregate of the whole committee and subtracts the absentees, which is far less curve arithmetic than adding up 400-plus signers. The finalized-header and next-committee facts are pulled out of the beacon state with SSZ Merkle branches at fixed generalized indices.
Anchoring a block
Verifying a committee signature tells the light client that some finalized Ethereum block is real. It then walks from that finalized header to the specific block a deposit landed in, and records one thing about it: the block's receipts root — the Merkle root of every transaction receipt Ethereum produced in that block.
That is the hinge. Once STRATO holds a receipts root it verified through Ethereum's own validators, it has a trustworthy fingerprint of everything that happened in that block — and any claim about a transaction in it can be checked against that fingerprint.
Proving your deposit
Your deposit into the vault emitted an event, which lives in that block's receipts. To claim it, someone submits a Merkle-Patricia proof that your receipt sits under the anchored receipts root, and the contract checks three things: that the proof is valid against the root it verified, that the log was emitted by the bridge vault and no other address, and — decoding the event — which token, how much, and which STRATO account it names.
Only then does it mint. A deposit maps through two route tables: one fixes which STRATO token a given Ethereum token becomes (USDC → USDλ), the other the decimal scale between them (USDC's 6 decimals to USDλ's 18, a factor of a trillion). If either route is missing, the deposit is rejected rather than minted — marked processed, never credited, and refundable back on Ethereum. With both in place, USDλ is minted to your STRATO wallet, or escrowed straight into your trading account.
Create or credit
Whether a deposit creates a new trading account or credits an existing one is resolved off chain and passed into the claim explicitly. Whether an account exists is rollup state the settlement chain cannot see, so it is never inferred on-chain — the intent travels with every claim, fill, and create variant. The fast fill below carries the same resolved intent, so a returning depositor is never mistaken for a new one.
Two speeds
Producing that proof needs the Ethereum block to be final — about 13 minutes. Waiting 13 minutes to start trading would be a poor welcome, so deposits run on two tracks at once.
On the fast track, a zero-fee house filler fronts your credit from its own USDλ the moment your deposit is seen, about a minute in. It binds the fill to the content of your deposit — the token, amount, and destination — not to any particular Ethereum transaction, so a reorg on Ethereum can't trick it into paying for a deposit that didn't stick. The filler, not you, carries that risk.
On the trustless track, once the block is final the light-client proof settles the deposit exactly as above — except that when a filler already fronted it, the freshly minted USDλ goes to the filler as reimbursement instead of to you. Both transactions are permissionless and each is verified on its own, so the worst a missing or misbehaving relayer can do is make you wait the 13 minutes; it can never cause a wrong credit.
One chain today
Everything on this page is running against Ethereum — Sepolia, on the current testnet. The design generalizes to any chain STRATO can run a light client for, and there are reserved seams for Base and Linea, but no other chain's vault, routes, or light client is deployed yet. Every live deposit is Ethereum → STRATO.