Autonomous Vaults Roadmap

Version: 0.1 (Draft) Date: July 25, 2026 Status: Forward-looking roadmap

1. Why Autonomous Vaults

Every yield product ultimately answers one question: who can touch the funds, and who decides what the vault does next? Today, across DeFi, the honest answer usually includes a team multisig, operator keys, and off-chain scripts.

Flare co-founder Hugo Philion has argued that “vaults need to transition to being autonomous programs running inside verifiable compute” — programs whose code is changeable only via governance, fed by protocol oracles, and able to execute across chains without human key-holders (X, July 23, 2026).

Flare is shipping the three primitives that make this possible:

Primitive	What it provides
Flare Confidential Compute (FCC)	Programs run in attested Trusted Execution Environments (TEEs). The exact code version (a reproducible build hash) is registered on-chain; results are signed and verified by smart contracts.
Flare oracles (FTSO + FDC)	Protocol-level input signals: decentralized price feeds (FTSO) and attested proofs of external-chain events, including XRPL transactions (FDC).
Protocol Managed Wallets (PMW)	Smart-contract-directed transaction signing on external chains — including the XRP Ledger — via k-of-n TEE multisig, with no single human-held key.

Shield Finance is an XRP liquid staking protocol that already lives on Flare. This roadmap describes how ShXRPVault progressively adopts these primitives to become an autonomous vault: one whose decision logic is verifiable, whose inputs are oracle-fed, and whose cross-chain execution requires no team-held keys.

2. Where Shield Is Today (v1)

ShXRPVault v1 is an ERC-4626 tokenized vault on Flare: users deposit FXRP (FAssets-wrapped XRP) and receive shXRP shares. Capital is deployed across yield strategies with an instant-withdrawal buffer (see ShXRPVault Specification).

Stated plainly, the v1 trust surface is:

Layer	Mechanism today	Verifiable by users?
Vault accounting — shares, fees, buffer	ShXRPVault (ERC-4626) on Flare	✅ Fully on-chain
XRP ↔ FXRP bridging	FAssets, secured by FDC payment proofs and agent collateral	✅ Protocol-level
Strategy allocation, harvests, rebalancing	Operator-triggered transactions from off-chain services	⚠️ Results on-chain; decisions off-chain
Vault parameters, strategy set, upgrades	Owner/operator keys held by the core team	❌ Requires trust in the team
Governance	SHIELD voting via the governance portal; execution by the team	⚠️ Signaling today

The first two rows are already trust-minimized. The roadmap below is about eliminating the last three.

3. Target Architecture (v2)

flowchart TB
  subgraph signals[Input signals]
    FTSO[FTSO price feeds]
    FDC[FDC attestations of XRPL events]
  end
  subgraph fcc[Flare Confidential Compute]
    FCE[Shield vault program<br/>attested TEE, governance-pinned code hash]
  end
  subgraph flare[Flare]
    VAULT[ShXRPVault<br/>ERC-4626]
    GOV[SHIELD governance<br/>code-version registry]
  end
  subgraph xrpl[XRP Ledger]
    PMW[Protocol Managed Wallet<br/>k-of-n TEE multisig]
  end
  FTSO --> FCE
  FDC --> FCE
  GOV -->|approves code versions| FCE
  FCE -->|signed, verified instructions| VAULT
  FCE -->|assembles and signs transactions| PMW

The vault’s decision layer — when to rebalance, when to harvest, how to route liquidity — moves from team-operated scripts into a Flare Compute Extension: a program running in an attested TEE whose build hash is pinned on-chain and changeable only through SHIELD governance. Oracles replace bespoke data plumbing. PMW replaces operational keys for anything that must happen on the XRP Ledger itself.

Flare primitive	Replaces in Shield
FCE program (attested, governance-pinned)	Off-chain keeper scripts and operator discretion
FTSO + FDC signals	Custom price polling and the in-house XRPL deposit listener
PMW execution on XRPL	Team-held operational keys
On-chain code-version registry	Advisory voting with manual execution

4. Phased Roadmap

Phase 0 — Hardening (now)

Gate: none — in progress. Continued security hardening of the v1 contracts, live governance portal usage, and public documentation of the current trust surface (this page). User-visible change: transparency, not mechanics.

Phase 1 — Research prototype on Coston2

Gate: FCC developer access (the extension scaffold requires infrastructure credentials from the Flare team). Build a prototype “vault brain” as an FCE on the Coston2 testnet — the same testnet ShXRPVault already deploys to. The prototype consumes FTSO/FDC signals inside the TEE and emits signed rebalance/harvest instructions that a verifier contract checks before execution, following the patterns in Flare’s FCC developer guides. User-visible change: none on mainnet; public repo and demo.

Phase 2 — Binding governance

Gate: FCC stable on Songbird (canary rollout approved by Flare governance, July 2026). Vault admin and keeper functions restricted to instructions originating from governance-approved FCE code hashes. SHIELD votes ratify each code version before it can act. Team emergency powers reduce toward pause-only. User-visible change: governance becomes binding — proposals change what the vault can do, not just what the team intends.

Phase 3 — Protocol-managed XRPL execution

Gate: FCC and PMW in production on Flare mainnet. XRPL-side operations are signed by a Protocol Managed Wallet — k-of-n TEE multisig under program control — retiring team-held operational keys entirely, and opening the door to native-XRPL strategy legs. User-visible change: “who holds the keys?” has a categorical answer: no one. An attested program does.

5. What Does Not Change

shXRP stays ERC-4626. Shares, deposits, and redemptions keep their current semantics and integrations.
FAssets remains the canonical XRP bridge (guide).
Fees and revenue split continue per the ShXRPVault Specification and SHIELD Tokenomics.

6. Trust Model, Stated Plainly

Verifiable compute is not magic, and this roadmap does not pretend otherwise:

TEEs add a hardware assumption. Attestation relies on confidential-VM hardware vendors. Mitigations in the FCC design: reproducible builds (anyone can rebuild the image and check the hash), multi-machine k-of-n execution, and an on-chain registry of attested machines.
Governance-only upgrades trade agility for credibility. Fixing or improving the vault program will take a vote, not a hotfix. We consider that the point.
FCC is pre-production. It is rolling out on Songbird (canary) first; Flare describes it as not yet a fully public production system. Phases 2 and 3 activate only as those milestones land.