FAssets is more XRPL-aligned than people think People ask how the FAssets system actually uses XRPL. The honest answer is that the FAssets core flow is built out of native XRPL primitives — four of them — and that's the architecture. 1. Destination tags. Minting FXRP means sending tagged XRP to the core vault. Redemption sends tagged XRP back to wherever the user wants it — an exchange, a custodian, a wallet. It's the same tag primitive XRPL users already rely on every day. EVM ecosystems are now trying to reinvent this with "subaccounts." XRPL has had it from day one. 2. Native signer sets. The core vault itself uses XRPL's built-in signer-set mechanism. Signers are visible on any explorer, and the vault only ever signs two transaction types: payments to agents on redemption, and escrows. Two native operations, both auditable on-chain. 3. Escrow. Large balances in any signer-controlled account benefit from additional protocol-level constraints. So FAssets continuously locks vault XRP into XRPL-native time-locked escrows that release on a rolling schedule. The liquid balance is always sized well above what's needed to keep redemptions flowing smoothly — the rest sits outside the signing scope until expiry, time-locked by the XRPL protocol itself. Why escrow rather than a custom contract? Because escrow is battle-tested, every XRPL explorer can verify the parameters independently, and standard XRPL operations are simple to validate and easy to monitor. 4. Memo fields. XRPL payments can carry memo data, and FAssets uses that to encode what the user wants to happen on Flare after the mint lands — buy a token, deposit into a vault, hit a Smart Account instruction. One XRPL transaction, full sequence on Flare. No new transaction types, no new wallet UX, no forks. Use XRPL the way it's designed. FAssets v1.3 is live on mainnet.