Fractal

frFB is FB, the native coin of Fractal Bitcoin, held in custody on Fractal and represented on Bitcoin as an alkane. It works the same way frBTC does, with one difference: the coin being locked lives on a different chain from the token being minted.

The short version

1. You lock FB on Fractal. You pay FB to the signer group's address, in a transaction that calls the fb-vault contract's Wrap. The transaction names who receives the frFB, and can carry an intent: arbitrary bytes saying what to do next.
2. fb-vault records the deposit. The amount is whatever the transaction actually paid the group. The contract also records the claimant and the intent bytes. Nothing is minted on Fractal.
3. The signer group mints frFB on Bitcoin. The FROST signer group (6-of-9 by protocol; today all seats are run by SUBFROST, see Security model) holds frFB's mint authority. It reads fb-vault's deposit log and mints frFB, less fees, to the claimant.
4. Redemption runs the other way. Burning frFB on Bitcoin records a Fractal destination in frFB's redemption queue. The group redeems it in fb-vault and pays the FB out of custody, with the Fractal network fees taken from the redeemed FB. See Redemption.

You do not have to build any of these transactions yourself. A gateway address can be derived from your intent alone. Any FB sent to it can be moved into the vault by anyone, and only into the vault, and the deposit pays for that move itself. See Gateway addresses and OP_CAT.

Two chains, two contracts, one group

	chain	id	what it is
fb-vault	Fractal	22:22	FB custody: the deposit log, the intents, the payment queue, the signer key
FB-SIGIL	Fractal	22:4222	one indivisible token; bearing it is the only way to rotate fb-vault's signer key. It stays inside the vault
frFB	Bitcoin	4:88888	the wrapped token, plus its redemption queue
frFB-AUTH	Bitcoin	2:102485	mint authority for frFB, held by the signer group
frFB-SIGIL	Bitcoin	2:102486	upgrade authority of the original deployment; it has no power over 4:88888, which cannot be upgraded

The signer group is a 6-of-9 FROST group by protocol. Today all nine seats run on one host operated by SUBFROST, so the threshold is not yet an operational security boundary; federation with external co-signers is in progress (see Security model). Its taproot address is the same string on both chains, because Fractal uses Bitcoin's address format:

bc1pt93aunap64ys8zlpmzc20z65a2vnmn0phrpc37kknve5835xsc9s6332rc

Current ids (since 9 October 2026)

frFB moved to 4:88888 and the Fractal side to protofractal protocol tag 12 (fb-vault 22:22, FB-SIGIL 22:4222) on 9 October 2026. frFB-AUTH and frFB-SIGIL are unchanged. Every gateway address changed with it: never reuse an address derived before that date. The history below (tag 44, 44:44, 4:4444) describes the original deployment.

On Fractal, that address is the vault's custody: fb-vault only credits FB paid to it. On Bitcoin, it holds frFB-AUTH, so only the group can mint.

Why the Fractal contracts have ids like 22:22

Fractal has no alkanes deployment path of its own. SUBFROST indexes it with protofractal, a separate protorunes subprotocol with protocol tag 12 (alkanes is tag 1). Its storage is namespaced by that tag, so it cannot collide with alkanes even in principle. protofractal has two contracts compiled into the indexer and installed at genesis: fb-vault and FB-SIGIL. It refuses every deploy. So nothing on Fractal can be replaced by a transaction; changing a contract means shipping a new indexer.

The ids sit on block 22, a block ordinary alkanes give no meaning to, so a protofractal call can never be mistaken for an alkanes deployment.

frFB, on the other hand, is an ordinary alkane on Bitcoin. It was deployed by witness reveal to the reserved id 4:88888 on 8 October 2026 (reveal 28c65d8c…1e46, block 970,543) and became the live frFB on 9 October. It is not upgradeable: it runs the original frFB code at a fixed address, and refuses Upgrade. The original deployment, at 4:4444 with protofractal on tag 44 (fb-vault 44:44, FB-SIGIL 44:4442), was retired on 9 October.

Authority, and how it can change

• Custody is a script comparison, not a signature check. Wrap sums the outputs that pay the vault's current signer script (opcode 104). FB paid anywhere else is not credited.
• Paying FB out (Redeem, opcode 79) needs a BIP340 signature from the group over the burn being redeemed, the amounts, the destination and a nonce. A captured signature can't be redirected, resized or replayed, and no burn can be redeemed twice. Signatures verify against the group's taproot output key, which is what its threshold signer produces.
• Rotating the signer key (SetSigner, opcode 1) needs no signature. It needs the caller to bear FB-SIGIL. A key that has been lost can't authorize its own replacement, but a bearer token outlives the key it governs. On the current deployment fb-vault's signer is the group key, and FB-SIGIL stays inside the vault (opcode 24 returns 1). On the original tag-44 deployment the sigil was released to the group's address (5b74991b…04f8) and used to rotate to the group key (c2b8c3f3…2414).
• Minting frFB needs frFB-AUTH. frFB can't be upgraded: 4:88888 refuses Upgrade (opcode 79), and the code it runs is a constant. frFB-SIGIL governed upgrades of the original deployment and has no power over the current one.

Intents

An intent is up to 4 KB of bytes attached to a deposit, telling the group what to do once the frFB exists: deliver it to a script, or carry out an action on it. fb-vault stores intents and never interprets them. Their meaning lives in the signer group's programs, so it can evolve without touching the contract. A deposit can carry its intent in either of two ways:

• A tapscript envelope in any input: OP_FALSE OP_IF "fb-intent" <bytes…> OP_ENDIF. This is how gateway addresses carry it, and it can be large.
• Extra words in the Wrap cellpack: [22, 22, 77, byte_len, w0, w1, …]. This is for a plain wallet deposit, and is limited by the 83-byte OP_RETURN.

The signer group acts on the action an intent carries: it can swap the frFB to BTC, DIESEL, FIRE or frUSD, add frFB/frBTC liquidity, or bridge out to USDC/USDT on an EVM chain, and split part of the value off as DIESEL or BTC gas, all in the mint's own transaction chain. See Intent Routes.

An envelope takes precedence over words. An intent that is missing, oversized or unreadable never blocks the deposit. By the time Wrap runs, the FB has already been paid, so the deposit is credited and the frFB goes to the claimant plainly.

Reading it yourself

All Fractal state is served at:

https://mainnet.subfrost.io/v4/{apikey}/fractal

This returns live alkanes state from protofractal (metashrew_view, metashrew_height), plus address balances, UTXOs and broadcast. The developer guide shows each request.

Fees

	where	amount (current settings)
gateway sweep	Fractal, taken from the deposit	K, 2,000 sats by default, fixed per address
mint	taken from the frFB minted	0.30% + 1,000 sats
route	withheld from a routed deposit	6 FB (routed deposits start at 7 FB; 30 FB for STABLE); see Intent Routes
redemption	taken from the FB paid out	the Fractal network fees of the two redemption transactions (protocol fee 0)

Example: 1 FB (100,000,000 sats) sent to a gateway address puts 99,998,000 sats in the vault and mints 99,697,006 frFB.

A real bridge, step by step

The first FB → frFB bridge on mainnet, on 6 October 2026, on the original deployment (tag 44, frFB 4:4444). Every number below can be checked on the explorers. Bridges on the current deployment, including every intent route, are in Mainnet examples.

step	chain	transaction	what happened
1. Deposit	Fractal	eda40cec…a0be	20 FB (2,000,000,000 sats) sent from an ordinary wallet to the gateway address bc1pw7zhtc3lzqz3z9pep65yca2kkvshcprx7n0g706lpl4805lq7l9svygrn7 (a tag-44 address, retired: never send FB to it)
2. Sweep	Fractal	7f8fb743…1d5b	the covenant spend: one input (the deposit), 1,999,998,000 sats to the vault, 546 sats to the claimant, the Wrap call in the OP_RETURN. The deposit paid its own 1,454-sat fee out of K (397 vB)
3. Credit	Fractal	fb-vault (then 44:44)	GetHeld = 1,999,998,000; the deposit and its intent are in the deposit log
4. Mint	Bitcoin	973920e8…5a15	signed by the signer group: 1,993,997,006 frFB to bc1ptttaar6ugd267nj2lg5ndxu9tcec96kllamqr9uzw7naruxxvlps2qf2vw (output 0), frFB-AUTH returned to the group (output 1). Confirmed in block 970,189

The mint amount is the vault credit less the mint fee: 1,999,998,000 − (0.30% × 1,999,998,000 + 1,000) = 1,993,997,006. After it, frFB's total supply was exactly 1,993,997,006.

The contract setup is on-chain too:

	transaction
frFB deployed to 4:88888 (current)	28c65d8c…1e46
frFB deployed to 4:4444 (original)	d2e644e9…663d
FB-SIGIL released from the vault (tag 44)	5b74991b…04f8
fb-vault signer rotated to the group key (tag 44)	c2b8c3f3…2414