« Index
State Connector
Web3 • Tools • Data Infrastructure
cross-chain event verification protocol on Flare
State Connector is Flare Network’s decentralized protocol for proving that events on external blockchains actually happened — without relying on bridges, centralized oracles, or trusted intermediaries. Where FTSO delivers continuous price data, State Connector answers a different question entirely: “Did this specific transaction on Bitcoin, XRP Ledger, Ethereum, or another chain actually reach finality?”
The system works through a network of independent attestation providers who monitor external chains and submit cryptographic proofs of observed events. When enough providers agree that a transaction occurred and reached finality on its native chain, the State Connector confirms it on Flare. Smart contracts can then trustlessly act on that proof — releasing collateral, triggering payments, or updating positions based on verified cross-chain activity.
This is the infrastructure that makes FAssets possible. To mint FXRP on Flare, the protocol needs trustless proof that real XRP was locked on the XRP Ledger. State Connector provides that proof without requiring users to trust a bridge operator or multisig committee. The same mechanic extends to any supported chain — enabling Flare smart contracts to react to Bitcoin transactions, Ethereum events, or Dogecoin movements with on-chain certainty.
Use Case: A user locks $XRP on the XRP Ledger to mint FXRP on Flare. State Connector attestation providers independently verify the lock transaction reached finality on XRPL, then confirm it on-chain. The Flare smart contract sees the verified proof and mints the corresponding FXRP — no bridge operator, no custodian, no trust assumption. The user then deploys FXRP into DeFi on Cyclo or Enosys Loans while their underlying XRP remains verifiably locked.
Key Concepts:
- FTSO — Sibling oracle system handling price feeds while State Connector handles event proofs
- $FLR — Native asset of the network where State Connector operates as core infrastructure
- Data Delegation — User-facing reward mechanic in the same oracle infrastructure family
- Interoperability — Cross-chain communication principle that State Connector enforces trustlessly
- Trustless — Architectural standard State Connector achieves by removing reliance on centralized verifiers
- Finality — Settlement confirmation that attestation providers must verify before proofs are accepted
Summary: State Connector is Flare’s cross-chain verification engine — proving external blockchain events on-chain without bridges, custodians, or trust assumptions. It completes Flare’s oracle-first architecture alongside FTSO and Data Delegation.
| Feature |
State Connector |
Cross-Chain Bridges |
Centralized Oracles |
| Verification Method |
Independent attestation provider consensus |
Multisig or validator committee |
Single trusted data source |
| Trust Assumption |
None — trustless by design |
Trust bridge operators won’t collude |
Trust the oracle provider entirely |
| Attack Surface |
Requires majority attestation provider collusion |
Bridge contracts exploitable — billions lost historically |
Single point of failure |
| What It Proves |
Specific transactions reached finality on external chains |
Token was deposited into bridge contract |
Data feed is current (no event verification) |
| Use Case |
FAssets, cross-chain settlement, trustless minting |
Token transfers between chains |
Price feeds only |
📡 State Connector Attestation Reference
how cross-chain proofs move from external chains to Flare smart contracts
| Stage |
What Happens |
Security Layer |
| Event Detection |
Attestation providers monitor external chain for target transaction |
Multiple independent providers watching same chain |
| Finality Confirmation |
Providers wait for transaction to reach irreversible finality on source chain |
Prevents confirmation of reversible or unfinished transactions |
| Attestation Submission |
Each provider submits cryptographic proof of the observed event |
Independent submissions prevent coordination attacks |
| Consensus Round |
Majority of attestation providers must agree on the event |
Byzantine fault tolerance across provider set |
| On-Chain Proof |
Verified proof available for any Flare smart contract to query |
Immutable on-chain record — no retroactive changes |
⚙️ Flare Oracle Infrastructure Map
how State Connector fits alongside FTSO and Data Delegation
| Component |
Function |
User Participation |
| FTSO |
Continuous decentralized price feeds for on-chain contracts |
Delegate $FLR to data providers for passive rewards |
| State Connector |
Cross-chain event verification and finality proofs |
Enables FAsset minting and trustless cross-chain actions |
| Data Delegation |
Token weight assignment to oracle providers |
Earn epoch rewards by backing accurate providers |
| Attestation Providers |
Independent operators verifying external chain events |
Infrastructure operators — technical participation only |
| FAssets |
Trustless wrapped assets backed by State Connector proofs |
Lock native assets, mint on Flare, deploy in DeFi |
✅ Cross-Chain Verification Trust Checklist
four-quadrant assessment for evaluating trustless verification systems
| Attestation Security |
Finality Standards |
| ☐ Multiple independent attestation providers required for consensus |
☐ Source chain finality confirmed before proof accepted |
| ☐ No single provider can forge or override proof |
☐ Reversible transactions rejected until settlement complete |
| ☐ Provider set decentralized — no operator concentration |
☐ Finality threshold matches source chain security model |
| Custody Integrity |
DeFi Deployment |
| ☐ Original assets verifiably locked — not held by custodian |
☐ Minted FAssets deployed into productive DeFi positions |
| ☐ Self-custody maintained via Ledger or Tangem |
☐ Yield stacked through Cyclo or Enosys alongside delegation |
| ☐ Redemption path verified — FAssets redeemable for underlying |
☐ Cross-chain position tracked through Bifrost interface |
🔄 Capital Rotation Map — State Connector Demand Across Market Phases
how cross-chain verification scales with capital movement through each cycle stage
| Phase |
Cross-Chain Activity |
Strategic Action |
| 1. BTC Accumulation |
Low cross-chain volume — infrastructure builds quietly |
Accumulate $FLR, delegate to FTSO, position for FAsset launch |
| 2. ETH Expansion |
DeFi protocols launch on Flare — State Connector demand rises |
Explore early FAsset minting — FXRP as first cross-chain yield layer |
| 3. Large Alt Rally |
Cross-chain capital flows accelerate as alts appreciate |
Deploy FAssets into DeFi — let State Connector proofs unlock liquidity |
| 4. Small/Meme |
Crowd chases memes — cross-chain infrastructure ignored |
Continue compounding FAsset positions while attention is elsewhere |
| 5. Peak Distribution |
Rotate speculative gains into verifiable cross-chain positions |
Redeem FAssets, take profit, increase $FLR delegation weight |
| 6. RWA Preservation |
Cross-chain settlement sustains utility through bear |
Park profits in $KAG/$KAU, maintain delegation, wait for next cycle |
Proof Over Trust: Every bridge hack in crypto history happened because someone trusted an intermediary instead of demanding proof. State Connector eliminates that assumption. It doesn’t ask you to trust a committee — it proves the event happened, verified by independent attestation providers with no shared incentive to collude. That’s the difference between a bridge and a protocol. Learn the full Flare infrastructure stack from
Mickey B. Fresh and The DeFi Standard Team, secure with
Ledger or
Tangem, and manage through
Bifrost.
« Index