Synthetic Assets

A SUBFROST synthetic asset is a coin from another chain, held in custody on that chain and represented on Bitcoin as an alkane. Each one is named fr + the coin's ticker: frSOL is SOL, frADA is ADA, frXRP is XRP, frZEC is ZEC, frFB is FB. One unit of the alkane is one unit of the coin in custody, at the coin's own smallest denomination.

They work the same way frBTC does, with one difference: the coin being held lives on a different chain from the token being minted.

asset	coin	foreign chain	custody on that chain	status
frSOL	SOL	Solana	the frsol-vault program	Live on mainnet (4:50050)
frXRP	XRP	XRP Ledger	a group account plus per-deposit addresses	Live on mainnet (4:50051)
frADA	ADA	Cardano	a Plutus V3 vault script	Live on mainnet (4:50052)
frZEC	ZEC	Zcash	a transparent, publicly auditable vault, with shielded deposits and payouts	Coming soon
frFB	FB	Fractal Bitcoin	the fb-vault contract and OP_CAT gateway addresses	Live on mainnet (4:88888). See Fractal

The short version

1. You deposit the coin on its own chain. The deposit says which Bitcoin script should receive the alkane. It is recorded by a contract (Solana, Cardano), or collected into a group-held account (XRP Ledger).
2. The signer group mints on Bitcoin. A FROST signer group holds the alkane's mint authority (its AUTH token). It reads the deposit from the foreign chain once that chain treats it as final, and mints the alkane, less a fee, to your Bitcoin script.
3. You burn to redeem. Burning the alkane on Bitcoin records a redemption at the burn's block height, naming where the coin should go on the foreign chain.
4. The group pays out. After the burn has enough Bitcoin confirmations, the group pays the coin out of custody to the destination the burn named, less the payout fee.

Nothing is minted that was not deposited first, and nothing is paid out that was not burned first.

Two keys on Bitcoin, one group on both sides

Each fr* alkane is deployed with two single-unit tokens:

token	who holds it	what it can do
AUTH	the signer group	Mint (opcode 77). Nothing else
SIGIL	SUBFROST's operator address, never the signer group	change the alkane's on-chain limits (opcodes 80–82) and record an upgrade (opcode 79)

AUTH and SIGIL are kept apart on purpose. If the key that mints could also change the mint cap, the cap would not bound anything. With them apart, a compromised minting key can mint at most one window's cap, and even the SIGIL holder can raise a limit only with a public delay (see Limits).

The signer group is a 6-of-9 FROST group by protocol, the same construction used for frFB. It holds two keys from the same set of seats: a taproot (BIP340) key on Bitcoin that holds AUTH, and an Ed25519 key that signs on Solana, Cardano and the XRP Ledger. See What you trust for how the seats are run today.

Custody on the foreign chain

Where the foreign chain can run contracts, a contract holds the coins and enforces its own rules. Where it can't, the group holds them directly.

• Solana (frSOL): a program vault. Deposits are SOL transferred into the vault's treasury, a system-owned account at an address derived from the frsol-vault program (a PDA) that only the program can sign for, each one leaving an on-chain deposit record. The program, not the signer group, enforces the deposit limits, the payout cap per window, at-most-once payment of every burn, pausing, and timelocks on every change that adds risk.
• Cardano (frADA): a script vault. Deposits are UTxOs at a Plutus V3 vault script address. The script admits them into a single state UTxO, identified by an NFT, and enforces the same set of rules as the Solana vault.
• XRP Ledger (frXRP): a group account. The XRP Ledger mainnet has no smart contracts, so XRP is held in an account whose key is the signer group's Ed25519 key. Each deposit goes to its own deposit address derived from the deposit's intent, which only the group can sign for. Limits and the payout cap are enforced by the signer group's programs, not by the ledger.
• Fractal (frFB): a covenant model. FB is held by fb-vault, a contract built into SUBFROST's Fractal indexer, and deposits can arrive through OP_CAT gateway addresses that can be swept into the vault by anyone, but only into the vault. See Gateway addresses and OP_CAT.

Intents: what travels with a deposit and a burn

Both directions carry bytes that say where the value goes.

• Deposit → mint. A deposit names the Bitcoin scriptPubKey that receives the alkane. frADA and frXRP deposits carry it inside a deposit intent (at most 512 bytes) in the byte format of frFB's gateway intents: the recipient script plus an optional action. frADA accepts versions 1 and 2. frXRP has its own version 2, which adds an XRP Ledger refund account for deposits whose address can't be swept. frSOL, the first of these to go live, takes the recipient script directly as an argument of the vault's deposit instruction.
• Burn → payout. A burn names the destination on the foreign chain. frSOL burns carry a 32-byte Solana public key. frADA and frXRP burns carry a release intent (at most 256 bytes): a version byte, the destination in the chain's own binary form, and an optional action.

Actions. frFB already executes intent routes as part of the mint. For frADA and frXRP the action field is part of the format from day one, but the first version executes only the plain route: mint the alkane to the recipient, or pay the coin to the destination. Any other action is delivered plain.

The exact byte layouts are in the developer reference.

Reading the foreign chain

A signer group is only as good as what it reads. The groups follow three rules:

• Several independent providers, which must agree. Every seat reads the foreign chain from at least three providers run by different operators, on different networks, and acts only when all of them agree on every field that decides anything. A disagreement or an unavailable provider means no progress that round, never a majority vote.

• Finality before anything is minted or paid. Each chain's own notion of final is used:

  chain	a deposit is used once	a burn is paid once
  Solana	the deposit record is read at finalized commitment	the burn has 3 Bitcoin confirmations
  Cardano	the ingest is 30 blocks deep (default)	the burn has 3 Bitcoin confirmations (default)
  XRP Ledger	the sweep is in a validated ledger (validated ledgers are final)	the burn has 3 Bitcoin confirmations (default)

• Replay before signing. Mints, payouts, frADA's vault transactions and frXRP's sweeps are simulated on their exact bytes before they are proposed for signing. If the simulation refuses one, or no simulation answer is available, nothing is signed.

Bitcoin-side reads (burn records, alkane balances) come from SUBFROST's own alkanes index. For frSOL, the group's own Bitcoin UTXOs are also cross-checked against a second, independently operated Bitcoin explorer.

Fees

	frSOL (current settings)	frADA (current settings)	frXRP (current settings)
mint fee, taken from the minted alkane	0.10%	0.10%	0.10%
payout fee, taken from the coin paid out	1,550,120 lamports flat (about 0.00155 SOL), a fee setting	1 ADA flat (never below 0.5 ADA); it pays the Cardano fee	12 drops flat by default (never below the network fee it pays)
other		a bounced deposit pays the vault's bounce fee, at most 1 ADA	the sweep of each deposit address costs the XRP Ledger's account-deletion fee (the owner reserve, 0.2 XRP at the time of writing), taken from the deposit

Bitcoin network fees for the mint are paid by the signer group. frFB's fees are on the Fractal overview.

Limits

Every fr* asset is bounded on both chains, so that a fault on either side has a known maximum cost.

• On Bitcoin, in the alkane:
  • a mint cap per window of window_blocks Bitcoin blocks (144 at launch, about a day). A window opens at the first mint after the previous window closed;
  • a max burn, the largest single burn the alkane accepts. A larger burn reverts and you keep your tokens;
  • hard ceilings compiled into the contract that no one can exceed, the SIGIL holder included.
• On the foreign chain: a minimum and maximum per deposit, and a payout cap per window. On Solana and Cardano the vault enforces these itself. On the XRP Ledger the signer group's payout program does.
• How they change: tightening is instant. Any raise is queued and public before it binds: 144 Bitcoin blocks (about 24 hours) in the alkane, and a timelock of at least 24 hours in the Solana and Cardano vaults. Anyone can read a queued raise (alkane opcode 23, GetPendingLimits). A queued raise is dropped by any later tightening, and expires if it is not executed in time.

	frSOL (live)	frADA (live)	frXRP (live)
deposit minimum / maximum	0.1 SOL / 1,000 SOL	10 ADA / 25,000 ADA	2 XRP (default) / no per-deposit maximum; the mint cap applies
payout cap (foreign chain)	1,000 SOL per ~24 h, enforced by the vault	100,000 ADA per 24 h, enforced by the vault	500,000 XRP per 144 Bitcoin blocks, enforced by the payout program
alkane mint cap per 144 blocks	4,000 SOL	100,000 ADA	500,000 XRP
alkane max burn	1,000 SOL	100,000 ADA	500,000 XRP
alkane hard ceilings	mint cap 10,000 SOL, max burn 4,000 SOL	mint cap 400,000 ADA, max burn 400,000 ADA	mint cap 2,000,000 XRP, max burn 2,000,000 XRP

All three columns are the live settings.

What you trust

Not yet independent signers

As with frFB, the nine seats of each signer group are run by SUBFROST, on infrastructure SUBFROST operates. The 6-of-9 threshold is a property of the protocol, not yet an operational security boundary. Until signing is federated with independent co-signers, every fr* asset trusts SUBFROST as custodian. See the frFB security model for the federation plan.

What limits that trust by construction, today:

• Caps bound the damage. A compromised minting key can mint at most one window's mint cap. A compromised payout key can move at most one window's payout cap from a contract vault, where the vault enforces it.
• No instant raises. Raising an alkane limit needs the SIGIL and waits 144 blocks. In the Solana vault (and the Cardano vault as designed), raising a limit, upgrading the program or replacing the signer group needs SUBFROST's operator key to co-sign and then waits a public timelock: 24 hours, or 72 hours to replace a group without its cooperation. The operator key is held offline and is a different key from the group's.
• An emergency stop. The operator key can pause the Solana vault (and the Cardano vault as designed) on its own. For frXRP, where there is no vault contract, a pause stops the signer group's programs. A paused vault pays nothing out (the Solana vault also refuses new deposits while paused). Resuming needs both the operator and the group.
• At-most-once by construction. Each burn has an identity derived from Bitcoin alone (its block height and its position among that block's burns). The vault refuses to pay any part of a burn twice, whatever the signer group asks.
• Upgrades are slow and checkable. The Solana vault program's upgrade authority is the vault itself. An upgrade must be queued with the hash of the new build, waits the timelock, and is refused if the uploaded program does not match that hash. On Bitcoin, opcode 79 Upgrade only records a target; it does not change the code that runs.

What you are trusting beyond that: SUBFROST as operator of the signer group and holder of the operator key and the SIGIL tokens, and SUBFROST's alkanes index as the source of burn records.

Next

• frSOL: live on mainnet. How to deposit SOL, burn frSOL, and what can go wrong.
• frXRP: live on mainnet. Deposit addresses, the gateway, burns with destination tags.
• frADA: live on mainnet. The Cardano vault, deposit datums, burns to Cardano addresses.
• frZEC: coming soon.
• Trading pairs: the fr*/frBTC pools on SUBFROSTAMM. Finding pools, quoting, swaps, liquidity, and wrapping BTC in the same transaction.
• Agents and automation: driving deposits, burns and payouts from a bot or an AI agent.
• frFB: FB on Fractal Bitcoin, with intent routes.
• Developer reference: intents, release intents, burn records, opcodes, and building a burn.