Your treasury.
Fully private.
Your treasury.
Fully private.
SILENT shields FXRP behind a commitment hash and settles every policy inside a TEE — proven on-chain, never revealed.
SILENT 2.0 — Confidential Treasury OS
Live on Flare Coston2Private intent.
Proven settlement.
Standing policy — a stop price, a payroll batch, a redemption intent — never touches the ledger. The TEE evaluates it privately, then settlement is proven on-chain: attestation, fresh FTSO price, FDC evidence.
From shield to settlement, every step on-chain.
Shield FXRP
FXRP moves into SilentVault behind a keccak commitment. No amount is ever stored or emitted on-chain — only the hash exists in public state.
Set a private policy
Prove & settle
Attest reserves
Built on Flare.
Every primitive is load-bearing.
Four Flare primitives chained into one flow — none of it works without the others, and none of the addresses are hardcoded.
FAssets custody
SilentVault holds real FXRP and resolves the live AssetManagerFXRP through FlareContractRegistry — never a hardcoded address.
FTSOv2 pricing
Stop-loss policies check the live XRP/USD feed inside the TEE before a settlement is ever signed.
FCC-pattern TEE
Private policy evaluation is impossible without confidential compute. SIMULATED_TEE today, real hardware tomorrow.
PMW-shaped settlement
Every settlement is authorized by a signed attestation verified on-chain — the shape a real k-of-n signer produces.
The settlement path, already executed.
Not a mockup. These are real transactions on Flare Coston2 — the full shield → encrypt → tick → settle → prove-reserves loop from docs/DEPLOY.md. Tap a hash to inspect it on the explorer.
Shield FXRP
1.0 FXRP pulled behind a keccak commitment — no amount on-chain, only the hash.
Set a private policy
A stop-loss policy encrypted client-side (ECIES to the TEE pubkey) — orderId 1.
Keeper forwards
A permissionless tick re-emits the ciphertext the keeper cannot decrypt.
Attested settlement
The TEE signed inside the enclave; on-chain, the attestation was verified, the FTSO price re-checked fresh, and 0.4 FXRP released.
Prove reserves
The TEE attested reserves above the threshold; an inflated threshold was refused (422) instead of forged.
Where standing intent becomes
on-chain proof.
What you plan to do stays private. What was done is attested — signed by the TEE, re-checked against a fresh FTSO price, anchored by FDC evidence. Shield first. Prove later.
Questions, answered honestly.
The short version of how SILENT works — and just as important, what it is not.
A confidential treasury OS on Flare. FXRP is shielded into SilentVault behind a commitment-only hash, policies are evaluated privately inside a TEE, and settlement is proven on-chain via signed attestation, a fresh FTSO price, and FDC evidence.
No. shield() stores only keccak256(amount + salt + user) — the commitment. No amount is ever stored or emitted, not even as a marketing stat. proveReserves proves a threshold without revealing the balance.
It holds your encrypted policy, polls the live FTSO feed privately, and decides when to settle: trigger prices, trailing stops, payroll batches, redemption destinations. The keeper that calls tick() can't decrypt anything — it only forwards bytes.
Honest answer: SIMULATED_TEE today. The enclave is a Go process with the same interface, signature scheme, and on-chain verification path production would use, but no remote attestation yet. Hardware attestation via TeeMachineRegistry is the roadmap.
Three checks in settle(): the TEE signature against the allowlisted signer, the FTSO feed re-checked on-chain for freshness (≤300s) and trigger condition, and the FDC Merkle proof when the path redeems to XRPL — recorded as CrossChainEvidenceRecorded.
Only the allowlisted TEE signer. The keeper is untrusted by design: anyone can run one, running zero just means orders wait for someone else to tick them. There is no owner withdraw and liabilities are isolated per vault.
Execution. Once settle() is a public transaction, its calldata is visible in the mempool like any other. What's hidden is standing intent — the policy itself — never the settlement. That is a deliberate, documented boundary, not an oversight.
Deployed and verified on Flare Coston2 (addresses in docs/DEPLOY.md) as a hackathon build with a real cryptographic core. Not audited, not mainnet. TRUST.md states exactly what's trusted versus what's verified — read it before treating it as production.
Shield your treasury. Prove on chain.
Hedge, pay, and redeem without revealing intent — commitment-only vaults, policies evaluated in the TEE, settlement attested on Flare.
Live on Flare Coston2 · attestation signer allowlisted on-chain