frSOL
frSOL went live on Bitcoin and Solana mainnet on 12–13 October 2026. The full lifecycle (deposit, mint, burn, payout, emergency pause and resume) has run on mainnet; the transactions are below.
frSOL is SOL held in custody by the frsol-vault program on Solana, and represented on Bitcoin as an alkane. 1 frSOL unit = 1 lamport: frSOL has the same 9 decimals as SOL.
Contracts and ids
| chain | id | what it is | |
|---|---|---|---|
| frSOL | Bitcoin | 4:50050 | the alkane, plus its burn queue |
| frSOL-AUTH | Bitcoin | 2:102983 | mint authority, held by the signer group |
| frSOL-SIGIL | Bitcoin | 2:102984 | limits and upgrade authority, held by SUBFROST's operator address, never the signer group |
| frsol-vault | Solana | program 25oyhHXj19hFvtut2Vd9fq3u3E2YJrHwQXoY7vRFpfBb | SOL custody: deposits, payouts, limits, pause and governance |
| Vault state | Solana | H9DgYrKMeQfUH4qrC1yFZ2QxZXThVrrCs7adtUyCGZqx | the Vault account (PDA, seed "vault") |
| Treasury | Solana | CanG1DgFswnD1wNMbUAgVPR4bh6mrhhmVNaez9Cg1EmV | the system account holding deposited SOL (PDA, seed "treasury") |
The signer group's Bitcoin address, which holds frSOL-AUTH and pays for mints, is:
bc1p6pxp3w2rgwsxyjtegr8fw9rlhha4gvfe6vwm5mjcejsaj9g3e7hsh90s88
On Solana the group's Ed25519 key is the vault's authority: it signs every payout. The vault's operator is a separate, offline key held by SUBFROST.
Depositing SOL
You call the vault program's deposit instruction with two arguments:
| argument | type | meaning |
|---|---|---|
amount | u64 | lamports to deposit |
btc_script | bytes | the Bitcoin scriptPubKey that receives the frSOL |
The program transfers amount from your wallet into the treasury and writes an immutable deposit record (seq, depositor, amount, btc_script, slot). The signer group reads deposit records at Solana's finalized commitment, and mints frSOL to btc_script, less the mint fee.
The recipient script. Only standard scripts are accepted: P2TR, P2WPKH, P2WSH, P2PKH and P2SH (at most 34 bytes). Use a taproot (bc1p…) address from a wallet that can hold alkanes. For example, the address bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr is the script:
5120 a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c
51 is OP_1, 20 pushes 32 bytes, and the 32 bytes are the address's witness program (its bech32m payload). Pass those 34 bytes as btc_script.
The deposit fails on Solana, and nothing leaves your wallet, if:
- the vault is paused;
amountis below the minimum (0.1 SOL) or above the maximum (1,000 SOL);btc_scriptis not one of the standard script shapes above;- another deposit landed first and took the sequence number you derived the record address from (retry with the new
next_deposit_seq).
You also pay the rent for your deposit record (a 102-byte account; 1,168,400 lamports at the first mainnet deposit). The record is permanent: it is the proof of your deposit that the mint is built from.
How to build the instruction yourself (accounts, data layout, the record's address) is in the developer reference.
Receiving frSOL
The group mints in rounds. Each mint is an ordinary Bitcoin transaction from the group's address, spending frSOL-AUTH and returning it to the group, and paying the frSOL to the btc_script of every deposit it covers. The mint also carries a marker of the deposit sequence numbers it covers, so a deposit can never be minted twice.
minted = amount − ⌊amount × fee_bps / 10,000⌋ − flat_fee
Today fee_bps is 10 (0.10%) and flat_fee is 0. 0.1 SOL (100,000,000 lamports) mints 99,900,000 frSOL units.
Redeeming: burn frSOL for SOL
Call frSOL's opcode 88, Burn, with the Solana public key that should receive the SOL. The burn burns every frSOL its protostone receives, so the transaction must deliver exactly the amount:
cellpack [4, 50050, 88, recipient0, recipient1]
receives exactly the frSOL to burn, and no other alkane
All alkanes on a transaction's inputs go to its first alkanes protostone, and a protostone's edicts run after its call. Either spend a UTXO that holds exactly the frSOL to burn and nothing else, or put a separate edict-only protostone before the burn that sends the exact amount to it and the rest back to you. Both shapes, with a worked frSOL example, are in the developer reference.
recipient0 and recipient1 are the 32-byte public key, bytes 0–15 and 16–31, each read as a little-endian u128. For the example key 4gJPamk7fDjNkY1rLVxrECa6jXMTpqgmLs16qEbwD1Vp (base58-decoded: 36a45fe165ee6c059fcbb8e6e5773bbfbefd121c2ce253b6b9027792e05e0f47):
[4, 50050, 88, 254191324530969493053561943663094768694, 94454996492546882319798964218521386430]
The burn reduces frSOL's supply and appends a record to the burn queue at the burn's Bitcoin height. After 3 confirmations, the group calls the vault's withdraw, which pays you:
paid = burned − 1,550,120 lamports
1,550,120 lamports is the payout program's flat fee setting, sized to cover the vault's on-chain receipt for your burn plus the Solana transaction fee. The payout transaction carries the memo frsol:burn:<height>:<index> (a payout made in parts adds :<part>/<parts>; match on the prefix), so you can find it from the burn.
The burn reverts, and you keep your frSOL, if:
- it carries anything other than frSOL, or more than one alkane;
- the amount is zero, or above the max burn (1,000 SOL today; split a larger amount into several burns);
- the recipient is the all-zero key;
- the same protostone already burned.
Burns that can't be paid as asked
Check these before you burn. In these cases the frSOL is burned:
- Too small. The payout program's minimum net payout is 890,880 lamports. A burn whose payout after the fee would be below it is absorbed: nothing is paid and the SOL stays in the treasury. Burn at least 0.002441 SOL (2,441,000 lamports). (Solana's own rent-exempt minimum for a plain account is lower, 650,240 lamports today; the payout program uses the higher figure.)
- A recipient the vault can't pay. The vault refuses to pay its own accounts, any account it owns, executable programs, and reserved system accounts. Such a burn is quarantined (voided on chain) so it doesn't block the burns behind it. SUBFROST's operator can later settle it to a recipient it has established belongs to whoever burned it; the vault co-signers accept that redirect only for a recipient that could not have been paid. Burn to an ordinary wallet address you control.
Large payouts and the payout cap
The vault pays out at most 1,000 SOL per window of 216,000 slots (about 24 hours), whatever the signer group asks. Burns are paid strictly in Bitcoin order. With today's settings the max burn equals the payout cap, so every burn the alkane accepts fits in one window, but if the window's remaining room is used up, the next payout waits for the next window. (The max burn can be raised, up to 4,000 SOL, without raising the vault's cap; the vault can pay a larger burn in up to 64 parts across windows.) The vault keeps an on-chain receipt for every burn it pays, which pins the recipient and amount and pays each part at most once.
Fees, limits and timing
| value | |
|---|---|
| deposit minimum / maximum | 0.1 SOL / 1,000 SOL |
| mint fee | 0.10% of the deposit (fee_bps 10, flat 0) |
| payout fee | 1,550,120 lamports, flat (a fee setting) |
| smallest payable burn | 2,441,000 lamports (0.002441 SOL) |
| max burn | 1,000 SOL (GetLimits, word 4) |
| mint cap | 4,000 SOL per 144-block window (GetLimits) |
| payout cap | 1,000 SOL per 216,000 slots (~24 h), enforced by the vault |
| hard ceilings | mint cap 10,000 SOL per window, max burn 4,000 SOL, vault payout cap 10,000 SOL per window |
| deposit used at | Solana finalized commitment |
| burn paid after | 3 Bitcoin confirmations |
Limits and fees are current settings. Tightening a limit takes effect at once. Raising one is queued: 144 Bitcoin blocks for the alkane's limits, and the vault's timelock (216,000 slots, about 24 hours) with the operator's co-signature for the vault's. You can read the live values:
- frSOL opcode 22,
GetLimits:mint_cap, window_blocks, window_start, minted_in_window, max_burn; - frSOL opcode 23,
GetPendingLimits: a queued raise, if any; - the
Vaultaccount:min_deposit,max_deposit,paused,withdraw_cap_per_window,window_slots, and any pending change (layout in the developer reference).
What can go wrong
| situation | what happens |
|---|---|
| the vault is paused | deposit fails on Solana (error Paused); your SOL stays in your wallet. Payouts wait until it is resumed |
| a deposit can't be minted | a deposit the mint can't carry is skipped for minting and quarantined, and its SOL stays in the treasury for the operator to settle. The vault's limits are set so an admissible deposit always fits |
| the burn is above max burn, zero, or to the all-zero key | the burn reverts; you keep the frSOL |
| the payout would be below the 890,880-lamport minimum net payout | absorbed: nothing is paid |
| the recipient can't be paid | quarantined; the operator may settle it to a proven recipient |
| the payout cap is reached | the payout waits for the next window |
| the replay of a payout fails | it is not signed; it is retried every round, and later burns wait behind it |
Security
frSOL follows the model in What you trust. Specific to frSOL:
- Custody is one operator today. The 6-of-9 signer group's nine seats are run by SUBFROST on one host. This is an accepted risk at launch, bounded by the vault's payout cap and the alkane's mint cap.
- What the operator key can do. Alone: pause the vault, and cancel any queued change. With the group: resume, raise a limit (after the 24-hour timelock), upgrade the program (after the timelock, and only to the exact build whose hash was queued), and replace the signer group (24 hours with the old group's cooperation, 72 hours without it).
- What the group alone can do. Pay burns (within the cap, each part once), quarantine an unpaid burn, tighten a limit, pause, and cancel a queued change other than a group replacement (only the operator can cancel a rotation or eviction).
- Program upgrades. The vault program's upgrade authority is a PDA of the vault itself, so no person's key can upgrade it directly. The deployed program is the reviewed build byte for byte.
- Reads. Solana state is read from three independent RPC providers run by different operators, which must agree at
finalized. Burn records are read from SUBFROST's alkanes index; the payout cap bounds the cost of a bad read.
The vault program, the frSOL alkane and the signing path went through four rounds of pre-mainnet review on 12 October 2026, and were deployed only after the final round found no open critical, high or medium issues outside the accepted risks described on this page.
Mainnet lifecycle
The first deposit, mint, burn and payout, and an emergency pause and resume, on 12–13 October 2026:
| step | chain | transaction | what happened |
|---|---|---|---|
| frSOL deployed | Bitcoin | 316da714…f828 | 4:50050, frSOL-AUTH 2:102983 and frSOL-SIGIL 2:102984 created (block 971,138) |
| AUTH to the group | Bitcoin | 7cc52ab4…ee9b | frSOL-AUTH sent to the signer group; frSOL-SIGIL kept by SUBFROST's operator |
| vault deployed | Solana | 3LgdjtfQ… | 25oyhHXj…pfBb |
| vault initialized | Solana | mFRwwod3… | authority = the group, a separate operator key, min 0.1 SOL, max 1,000 SOL; the program's upgrade authority handed to the vault's own PDA |
| 1. deposit | Solana | 3udxWGuN… | 0.1 SOL, deposit seq 0 |
| 2. mint | Bitcoin | 34899b1a…0a13 | signed by the group: 99,900,000 frSOL to the deposit's script (block 971,187); AUTH returned to the group |
| 3. burn | Bitcoin | e27df8dc…7b34 | 99,900,000 frSOL burned (block 971,189), burn id 971189:0 |
| 4. payout | Solana | 5hfHksmv… | withdraw, memo frsol:burn:971189:0: 98,349,880 lamports paid (99,900,000 − 1,550,120) |
| pause | Solana | 3fRUyZRU… | emergency pause by the operator key alone; deposits refused with Paused |
| resume | Solana | 4oyc7NFx…, 5QZQ9yS7… | the operator's signed instruction recorded, then unpause signed by the group and co-signed by the operator |