frADA

Live on mainnet

frADA is live: the signer group ingests deposits into the vault on Cardano, mints frADA on Bitcoin and pays burns out in ADA. The first full cycle ran on 14 October 2026 (see Mainnet lifecycle). Start with a small amount, and check the vault address below before you send anything.

frADA is ADA held in custody by a Plutus V3 vault script on Cardano, and represented on Bitcoin as an alkane. 1 frADA unit = 1 lovelace: frADA has the same 6 decimals as ADA.

Contracts

	chain	id	what it is
frADA	Bitcoin	4:50052	the alkane, plus its burn queue. Deployed in 0098eced…5915
frADA-AUTH	Bitcoin	2:103101	mint authority, held by the signer group
frADA-SIGIL	Bitcoin	2:103102	limits and upgrade authority, held by SUBFROST's operator address, never the signer group
vault	Cardano	addr1w8a45tdfg0wnxtpcnuna7l4nez84m3n5w74ulvlsj63jlhgwqd6cr	a Plutus V3 script (hash fb5a2da943dd332c389f27df7eb3c88f5dc67477abcfb3f096a32fdd); its address holds the deposits and the vault's state UTxO
state NFT	Cardano	policy ec11246196d74089807e01183c86b2889c562dcdcb995cceb8b17757, name frada-state	marks the one state UTxO; there is exactly one

The vault keeps all of its state in one state UTxO at the vault address, identified by an NFT named frada-state. That UTxO holds the treasury (ADA only) and an inline datum with the vault's state: the group's and the operator's key hashes, the deposit counter, the burn cursor, the pause flag, the limits, the bounce fee and any queued change.

Depositing ADA

1. Send ADA to the vault script address in a UTxO carrying an inline Deposit datum: your deposit intent (where the frADA goes on Bitcoin) and a Cardano refund address. ADA only: no native assets.
2. The group ingests it. Once your deposit is 30 blocks deep, the group spends it together with the state UTxO in an Ingest. The vault script checks the deposit, adds its ADA to the treasury and gives it the next deposit sequence number. Ingests carry up to 40 deposits and run while the vault is paused too.
3. The group mints frADA to the intent's recipient script on Bitcoin, less the mint fee, once the ingest transaction is itself 30 blocks deep.

The deposit intent (at most 512 bytes) is frFB's gateway intent, version 1 or 2, with a recipient script of 1–75 bytes. Only its recipient script and its action are read; the refund key, CSV and sweep fee fields are skipped, because the Cardano refund is the datum's refund address. The first version delivers every action as plain frADA. Details: developer reference.

The datum, as Plutus data: Deposit = Constr 0 [ intent : bytes, refund : Address ], with the ledger's standard Address encoding. It must be inline. Plutus data byte strings longer than 64 bytes must be written as an indefinite-length string of 64-byte chunks (5f 5840… ff); a typical intent with a taproot recipient is 72 bytes, so this applies. Some libraries emit one long string, which the node refuses.

Bounces

A deposit that can't be accepted is bounced: paid back to its refund address with every native asset it carried and its ADA less the vault's bounce fee (at most 1 ADA). The bounce output carries the deposit's own output reference as its datum, so one bounce can never stand in for two deposits. A deposit is bounced if:

• it carries any native asset besides ADA;
• its ADA is below the minimum or above the maximum deposit;
• its intent is over 512 bytes, can't be decoded, names a recipient script that can't be paid, or names the signer group's own script.

A deposit too small to cover the bounce fee and Cardano's minimum UTxO for the refund is bounced with a subsidy from the group of up to 1 ADA, or else left at the vault address.

Some UTxOs can never be spent. A UTxO at the vault address with no datum, or with a datum that is not a Deposit, can't be ingested or bounced by anyone. One with a hashed (not inline) Deposit datum can be bounced but not ingested. Always attach an inline Deposit datum.

Redeeming: burn frADA for ADA

Burn frADA on Bitcoin with a release intent naming a Cardano address:

cellpack   [4, 50052, 88, len, w0, …, w(n-1)]
receives   exactly the frADA to burn, and no other alkane

release intent v1 = 0x01 ‖ addr_len (1 byte) ‖ raw Cardano address ‖ action (empty = plain)

The release intent is at most 256 bytes. Its usable length is 31–256 bytes: the shortest valid one is an enterprise address (29 bytes) plus the two header bytes. len is its length, and the words w0… are its bytes, 16 per word, little-endian. Encoding, with worked examples, is in the developer reference.

The burn burns every frADA its protostone receives

An edict in the burn protostone does not limit it. Spend a UTXO holding exactly the frADA to burn and no other alkane, or put an edict-only protostone before the burn that sends it the exact amount. See Getting the amount right, which has a worked frADA example.

The address must be a mainnet Shelley payment address: base (57 bytes), enterprise (29 bytes) or pointer (32–59 bytes). The burn reverts, and you keep your frADA, on:

• a zero amount, or one above the max burn;
• a release intent that isn't version-1 shaped;
• a Byron, reward, reserved-type or testnet address;
• non-zero words after the intent;
• a second burn in the same protostone.

Payout

After the burn has 3 Bitcoin confirmations, the group pays the ADA from the treasury in a Payout: burns strictly in Bitcoin order, up to 20 per transaction, within the vault's window cap.

paid = burned − flat payout fee   (1 ADA by default)

The payout fee pays the Cardano transaction fee, which the group covers.

Burns that are voided

The alkane only checks the address's shape. A burn it accepts but the group can't pay is voided: the vault's cursor passes it and nothing is paid, though the frADA is already burned. This happens when:

• the release address doesn't decode;
• it is the vault script itself, or the signer group's wallet;
• the payout after the fee would be under Cardano's minimum UTxO for that output;
• the payout after the fee is more than the vault's whole window cap.

The vault lets the operator and the group together settle a voided burn later, paying it to an address the operator approves. Settling isn't automatic: check the address and amount before you burn.

Fees, limits and confirmations

	value	where it comes from
deposit minimum / maximum	10 ADA / 100,000 ADA	planned launch values; the vault accepts any setting from 1 ADA to 1,000,000 ADA
vault payout cap	100,000 ADA per 24 h	planned launch value; enforced by the vault script
alkane mint cap	100,000 ADA per 144 blocks	compiled default
alkane max burn	100,000 ADA	compiled default
alkane hard ceilings	mint cap 400,000 ADA, max burn 400,000 ADA	compiled
mint fee	0	the mint program's default; the launch setting will be listed here
payout fee	1 ADA, flat	the payout program's default; never below 0.5 ADA
bounce fee	at most 1 ADA	the vault's hard bound; the launch value will be listed here
deposit depth	30 Cardano blocks for the ingest, and 30 again for the mint	default
burn confirmations	3 Bitcoin blocks	default

Tightening a limit is instant. Raising one waits 144 Bitcoin blocks in the alkane, or the vault's timelock (at least 24 hours) with the operator's co-signature in the vault.

What can go wrong

situation	what happens
your deposit carries a native asset, is out of range, or its intent is bad	bounced to your refund address, less the bounce fee
your deposit has no datum, or a datum that isn't a Deposit	it can never be spent: the ADA is stuck
your deposit has a hashed Deposit datum	bounced, never ingested
the vault is paused	deposits are still ingested; payouts wait until it is resumed
the burn is zero, above max burn, or to a malformed or testnet address	the burn reverts; you keep the frADA
the burn's address is the vault or the group's wallet, the payout is under the minimum UTxO, or over the whole window cap	voided; the operator and group may settle it later
the window's payout cap is used up	the payout waits for the next window

Security, as designed

frADA follows the model in What you trust, with the same governance matrix as the frSOL vault:

• The group alone ingests deposits, pays burns in order within the window cap, voids an unpayable burn, tightens a limit, pauses, and cancels a queued change other than a group replacement.
• The operator alone can pause and cancel any queued change.
• The group and the operator together resume, settle a voided burn, and queue changes that add risk: raising a limit, changing the timelock, replacing the group, or migrating the vault to a new script (Plutus scripts can't be upgraded in place). Each waits a timelock of at least 24 hours; replacing a group without its cooperation waits 72 hours.
• Never pay twice. The vault records the highest burn it has ever paid. If the cursor is ever moved back, a payout of any burn at or below that mark needs the operator too, so the group alone can never pay a burn twice.
• Reads come from at least three independent Cardano API operators, which must agree.

A risk specific to Cardano: everything goes through the single state UTxO, so a compromised group could keep spending it every block to race the operator's pause. The per-window payout cap bounds what that can cost.

Mainnet lifecycle

The deployment and the first full cycle on 13–14 October 2026:

step	chain	transaction	what happened
frADA deployed	Bitcoin	0098eced…5915	4:50052, frADA-AUTH 2:103101, frADA-SIGIL 2:103102 (block 971,342)
AUTH to the group	Bitcoin	cd770d0e…d24e	frADA-AUTH to the signer group; frADA-SIGIL kept by SUBFROST's operator
vault initialized	Cardano	41e911d8…	co-signed by the deployer and the operator, signed by the group: the state UTxO with 10 ADA and the frada-state NFT
1. deposit	Cardano	d0e38d9b…	12 ADA to the vault with a Deposit datum
2. ingest	Cardano	c7b3b256…	the group ingests it: deposit seq 0, treasury 22 ADA
3. mint	Bitcoin	f766b572…aa04	11,988,000 frADA (12 ADA less 0.10%) to the intent's script (block 971,377)
4. burn	Bitcoin	f33e0de1…a502	11,988,000 frADA burned to a Cardano enterprise address
5. payout	Cardano	a061c87a…	10,988,000 lovelace paid (11,988,000 − 1 ADA flat fee); the treasury keeps the fee