Flux

Non-custodial yield for native XRP/BTC on Flare — secured by verifiable off-chain compute, not off-chain trust.

Comment

Flux — Non-Custodial Yield Vault for Native XRP on Flare

Problem Statement

Native XRP is one of the largest, oldest assets in crypto — and one of the hardest to put to work. Every existing path to yield means wrapping it, bridging it, or handing it to a custodian, and trusting that they won't get hacked, rug, or simply disappear.

Flare's FAssets system solves half of that problem: it lets native XRP become usable in DeFi without a custodial bridge. But the other half — deciding where that capital should go, and proving that decision wasn't tampered with — usually still comes down to trusting an off-chain script's word for it.

Solution

Flux is a non-custodial ERC-4626 yield vault for native XRP on Flare. Deposit XRP, receive Flux shares, and let the protocol handle everything else — deposits are verified by cryptographic proof, and every rebalance is signed by a Trusted Execution Environment and checked on-chain before a single token moves.

Its unique value: Flare Confidential Compute (FCC) runs the off-chain yield-optimization logic inside a Trusted Execution Environment and lets the result be verified on-chain via a real cryptographic signature — not "trust us," but "check the signature." That's the primitive Flux is built around, so the off-chain logic isn't just faster, it's provably correct.

Key Features

  • FDC-Verified Deposits — every deposit is backed by a Flare Data Connector proof of the real XRPL payment, checked on-chain by Flare's own FAssets AssetManager. No off-chain program's word is ever trusted.
  • TEE-Signed Rebalancing — Flare Confidential Compute runs yield-optimization logic inside a TEE; its signed result is verified on-chain (3-layer EIP-191) before funds move.
  • Genuinely Non-Custodial — users hold Flux shares 1:1 backed by their deposit; only the depositor can redeem, and no admin key can move funds without a valid TEE signature.
  • Multi-Strategy Allocation — capital is automatically routed across yield strategies as market conditions change.
  • UUPS Upgradeable — the protocol can be improved without migrating user funds, gated entirely behind owner-only, non-custodial admin functions.

How It Works

  1. User sends XRP to Flare's Core Vault with a unique destination tag.
  2. The Flare Data Connector attests the payment; the app relays that proof.
  3. FdcDirectMintAdapter submits the proof to FAssets' AssetManager, which verifies it cryptographically and mints FXRP — no off-chain party asserts this happened, the chain checks it.
  4. The vault periodically requests a rebalance from the FCC-registered TEE.
  5. The TEE computes the optimal allocation and signs its result; the vault verifies that signature on-chain against the TEE's registered identity.
  6. Capital deploys into the approved strategy.

Live Demo & Deployments

Smart Contracts on Flare Coston2 Testnet

Contract Address
ParentVault (ERC-4626, UUPS proxy) 0x01f64160E4928Eba5607aE294F9B66090Dc323B3
InstructionSender (FCC) 0x94A838fb58B226b0EB01Fa8DdE3758806AcE1Ba7
FdcDirectMintAdapter 0x953Bfd3de0C0f994e280B5981642E711b3beE4eC
FTSO v2 Strategy Adapter 0xc529Eb4a03EC14E58598D03058DBb43B75059851

How We Built It

Smart Contracts (Solidity, Foundry)

  • ParentVault.sol — ERC-4626 vault, UUPS upgradeable, verifies TEE-signed rebalance results on-chain via a 3-layer EIP-191 signature scheme.
  • FdcDirectMintAdapter.sol — consumes Flare Data Connector proofs and forwards verified mints to the vault.
  • InstructionSender.sol — dispatches rebalance requests into Flare's shared TEE registry.

FCC Extension (TypeScript, Docker, running inside a TEE) Handles VAULT_REBALANCE instructions: computes optimal strategy allocation off-chain, returns an unsigned result that Flare's TEE node signs with its registered identity before it's ever usable on-chain.

Data Connector Integration Client-side proof retrieval against Flare's public Data Availability API, consumed on-chain by FAssets' AssetManager — the actual trust boundary is the protocol's own verifier, not our code.

Frontend (React, Vite, TypeScript, viem) Deposit flow, wallet connection, and real-time on-chain status polling.

Challenges We Ran Into

  • Storage layout on an upgradeable contract is unforgiving. An emergency recovery upgrade accidentally reintroduced an older contract version, silently corrupting which storage slot the vault's owner and signer fields actually read from — no revert, just wrong values everywhere. We fixed it by reconstructing the real deployed variable order from git history and on-chain storage reads, then enforcing a strict rule going forward: new variables only ever get appended, never inserted.
  • A TEE's identity isn't permanent. Every full rebuild of our TEE container rotated its enclave signing key, silently invalidating on-chain registration. We learned to never trust a cached "this machine is live" claim — always re-verify status directly on-chain before wiring anything to it.
  • Off-chain trust is a liability, not a shortcut. Our first deposit design used a watcher bot that observed XRPL and asserted a payment had happened. It worked for a demo and would have been trivially exploitable in production — anyone could claim a deposit they never made. We rebuilt the entire path around the Flare Data Connector specifically so the chain verifies a cryptographic proof, not a program's word.
  • Signature encoding is not standardized across the stack. Our TEE's raw ECDSA output used recovery IDs of 0/1; our on-chain verifier expected the Ethereum convention of 27/28. A one-byte mismatch that looked like a broken signature was actually just a format gap.

Accomplishments We're Proud Of

  • Zero-trust deposits: every FXRP mint is backed by an on-chain-verified cryptographic proof, not an off-chain claim.
  • Real TEE-signed rebalancing: a live, on-chain EIP-191 signature from a registered Trusted Execution Environment gates every fund movement.
  • Actually non-custodial: no key we hold, including the deployer's, can move user funds without a valid TEE signature.
  • Built on two of Flare's newest primitives at once — FAssets and Flare Confidential Compute — while both were still in their final development stages.

What We Learned

  • Off-chain claims aren't security — cryptographic proofs are.
  • A TEE's identity should be treated like a rotating credential, not a fixed address.
  • "Confidential compute" doesn't mean "trust us" — it means the result comes with a signature you can check yourself.
  • Testnet infrastructure is genuinely fragile; designing for that (careful upgrade discipline, fresh-registration paths, explicit verification at every step) matters as much as the core product logic.

What's Next for Flux

  • Bitcoin support — extend the same FDC-verified deposit path to native BTC via FAssets.
  • Additional strategy adapters — expand beyond FTSO v2 delegation into lending and DEX liquidity provision.
  • Mainnet deployment — move from Coston2 to Flare mainnet with full hardware TEE attestation.
  • Broader TEE governance — replace single-owner admin control with a distributed signer set.

Built With

  • Blockchain: Solidity, Foundry, Flare Network (Coston2 Testnet), Flare Confidential Compute (FCC), Flare Data Connector (FDC), FAssets
  • Off-chain / TEE: TypeScript, Docker, Trusted Execution Environment
  • Frontend: React, Vite, TypeScript, viem
  • Standards: ERC-4626, EIP-191, UUPS

Try It Out

Built With

Share this project:

Updates

Submission history