A wallet signature is a proposal, not permission.
An EVM approval can give an application authority over every token in a wallet. Serein moves the protected balance into a vault that has no generic approval path and requires two independent authorities for every exit.
The wallet still submits the transaction, but a registered FCC machine also has to approve the exact operation, destination, amount, live FTSO price epoch, nonce, policy version, and deadline. Large actions additionally require the passkey enrolled in the encrypted policy.
- 01
Open an isolated vault
Each owner gets a dedicated contract. FXRP can be deposited or direct-minted from XRP straight to that address.
- 02
Encrypt the policy
Recipients, dollar caps, and the passkey credential are encrypted to FCC. Only a commitment and ciphertext reach the public chain.
- 03
Request, verify, execute
An on-chain instruction routes to FCC. The enclave independently reads Flare state, verifies the policy, and returns one-use authorization.
- 04
Recover without bypassing policy
A guardian can lock the vault. Delayed emergency recovery redeems the full balance only to the precommitted XRPL address.
What we use from Flare.
Two bounty tracks, one coherent transaction path: FAssets plus FDC move XRP across chains; FTSOv2 and FCC govern what may leave the vault.
FAssets / FXRP
XRP enters as FXRP through FAssets and can direct-mint straight to an isolated vault. Redemption settles only to its committed XRPL address.
Evidence, not integration badges.
Every authorization starts in an on-chain FCC instruction, and every vault verifies the registered TEE signature plus the current FTSOv2 price.
- Vault factory
- 0x5145B7Ad…73C188Ac
- FCC instruction sender
- 0x380F1Cd0…14918735
- FCC machine
- 0xa752683D…2484fB8b