Proof
SIMULATEDWhat you are trusting, and what you can check
Everything a reviewer needs to verify the claims made elsewhere in this interface, including the parts that are not trustless yet.
Today
TrustedAttested XDC state
A single Helix signer observes the masternode and signs that observation onto Starknet. You are trusting one operator.
Next
Reduced trustm-of-n attester quorum
Independent operators must agree on the same reading before it finalises. The code path exists today and is exercised at 2-of-3 in the test suite; only the configured threshold differs.
Then
TrustlessSTARK proof of XDC consensus
A light client proves XDC consensus directly on Starknet. No signer is in the path at all.
XDC and Starknet are not natively connected, and there is no trustless bridge in this system. Saying so plainly is the point of this page — the same proving stack that makes hstXDC transfers private is the stack that eventually makes the bridge trustless, which is why the roadmap is one technology rather than a feature list.
Custodied versus attested
The redemption rate is priced from what the vault demonstrably holds on Starknet, not from what the oracle claims. These two numbers should track each other closely; the gap between them is the check on the attester.
Custodied on Starknet
294,000
Attested by the oracle
294,000
Variance
0.00%
Attestation history
| Epoch | XDC block | Staked | Rewards | Backing | Rate | Source | Tx |
|---|---|---|---|---|---|---|---|
| 13 | 93,190,195 | 280,000 | 14,000 | 294,000 | 1.05000000 | SIMULATED | 0x000000…f698 |
| 12 | 93,190,180 | 280,000 | 13,999 | 293,999 | 1.04999992 | SIMULATED | 0x000000…776b |
| 11 | 93,190,165 | 280,000 | 13,999 | 293,999 | 1.04999985 | SIMULATED | 0x000000…f83e |
| 10 | 93,190,150 | 280,000 | 13,999 | 293,999 | 1.04999977 | SIMULATED | 0x000000…7911 |
| 9 | 93,190,135 | 280,000 | 13,999 | 293,999 | 1.04999970 | SIMULATED | 0x000000…f9e4 |
| 8 | 93,190,120 | 280,000 | 13,999 | 293,999 | 1.04999962 | SIMULATED | 0x000000…7ab7 |
| 7 | 93,190,105 | 280,000 | 13,999 | 293,999 | 1.04999954 | SIMULATED | 0x000000…fb8a |
| 6 | 93,190,090 | 280,000 | 13,999 | 293,999 | 1.04999947 | SIMULATED | 0x000000…7c5d |
| 5 | 93,190,075 | 280,000 | 13,999 | 293,999 | 1.04999939 | SIMULATED | 0x000000…fd30 |
| 4 | 93,190,060 | 280,000 | 13,999 | 293,999 | 1.04999932 | SIMULATED | 0x000000…7e03 |
| 3 | 93,190,045 | 280,000 | 13,999 | 293,999 | 1.04999924 | SIMULATED | 0x000000…fed6 |
| 2 | 93,190,030 | 280,000 | 13,999 | 293,999 | 1.04999916 | SIMULATED | 0x000000…7fa9 |
| 1 | 93,190,015 | 280,000 | 13,999 | 293,999 | 1.04999909 | SIMULATED | 0x000000…007c |
Oracle freshness window: 300s. The vault refuses to mint against a stale attestation rather than guessing at a rate.
Contracts
How STRK20 proofs are produced
A private transaction is proved by executing it against an anchored recent-block snapshot inside a stripped-down virtual Starknet environment, then proving that execution with Stwo. The sequencer verifies the proof before the transaction executes.
SNIP-36 "Virtual Blocks" generalises exactly this primitive: a single transaction executed off-chain against a reference block and proven correct rather than re-executed by every node. It is the same machinery that would eventually carry a proof of XDC consensus onto Starknet — which is what turns the attester in the diagram above into a redundant component.