Smart wallets
Non-custodial design
Users hold their own BLS12-381 private keys. The sequencer never has access to user funds or signing capabilities. All operations are signed client-side before submission.BIP-322 signature verification
All operations — deposits, swaps, liquidity operations, and withdrawals — require a BIP-322 signature from the user’s Bitcoin wallet as an additional security layer. This is enforced by the sequencer to protect users from unauthorized operations. The first operation for every wallet is a deposit, which establishes the binding between the Bitcoin wallet and the BLS public key. The deposit authorization message format is:Pubkey index system
To optimize on-chain storage, public keys are assigned a sequential index. This allows operations to reference a compact identifier instead of the full 256-byte BLS public key, significantly reducing transaction sizes and inscription costs.Replay protection via nonces
Each wallet maintains a nonce that is atomically incremented with every operation. The nonce is included in the signed message, preventing replay attacks:Bitcoin batch settlement
Operation queue
User operations (swaps, liquidity adds/removes, withdrawals) are queued by the sequencer, which monitors pending operations and aggregates them into batches.Batching triggers
A new batch is created when either condition is met:
This ensures withdrawals are processed promptly while maintaining efficient batching for regular operations.
Compression
Batch data is compressed before inscription to minimize fees:- Zstd compression (level 22, maximum) is attempted first.
- NADA encoding is used as fallback if it produces smaller output.
- A 1-byte prefix indicates the encoding:
0x01= NADA,0x02= Zstd.
Sequential execution
Once the batch is inscribed and mined, the BRC-20 EVM executes operations sequentially at the mined block height. The system uses the transact command (signed EVM transactions) rather than simple calls for two reasons:- Key rotation resilience: If the batch sender wallet key is compromised, operations can continue from a different wallet without interruption.
- Nonce-based ordering: The EVM transaction nonce enforces sequential execution on the BRC-20 side, preventing out-of-order processing.
BLS signatures
Cryptographic foundation
The system uses BLS12-381, a pairing-friendly elliptic curve providing 128-bit security. This curve is widely used in blockchain systems (Ethereum 2.0, Zcash) and enables efficient signature aggregation. Signatures are computed on the G1 curve (shorter representation), while public keys reside on G2. This optimizes for aggregation efficiency since signatures are aggregated more frequently than public keys.Message format
Each operation’s signed message is constructed as:Signature aggregation
Individual signatures from multiple operations are aggregated into a single signature per batch:processBatch() function for on-chain verification.
N signatures compress to 1 aggregated signature, providing constant verification cost regardless of batch size. This dramatically reduces on-chain verification costs and inscription sizes.
BTC-frBTC wrapping
Wrap: BTC to frBTC
1
Construct the call inscription
User constructs a
wrapAndExecute2() call inscription.2
Send BTC to the handler wallet
BTC is sent to the handler wallet in the send-to-OP_RETURN transaction.
3
Sequencer validates
The sequencer checks transaction structure and signatures, fee rate within acceptable range, and mempool acceptance via
testmempoolaccept.4
frBTC minted
Upon inscription confirmation, frBTC is minted to the user’s balance.
- Token address
- Ticker index
- User pubkey and pubkey index
- BLS signature for emergency withdrawal
- EC signature for index verification
Unwrap: frBTC to BTC
1
Submit BLS-signed unwrap request
User submits a request containing: public key and nonce, output pkscript (destination), and amount and BTC fee.
2
Signature verification
The sequencer verifies the signature against the message:
3
Queue and process
The operation is queued and processed in the next batch.
4
BTC output created
A BTC output is created to the specified pkscript.
Minimum unwrap amount: 1000 satoshis.
Custody model
The BTC handler wallet is secured by a multisig arrangement operated by Subfrost.
Roadmap: The custody model will transition from internal Subfrost signers to an independent committee approach, distributing trust across multiple parties external to the core team.
Security
Trust model
Roadmap — Force exit mechanism: A force exit mechanism is planned to eliminate sequencer liveness trust. This will allow users to withdraw funds directly on-chain if the sequencer becomes unresponsive, ensuring users are never locked out of their assets.
Bitcoin finality and reorg handling
The system monitors block hashes on both Bitcoin and BRC-20 chains. On reorg detection:1
Detection
Block hash mismatch triggers the reorg handler.
2
Wait for sync
System waits for BRC-20 to process the reorg.
3
Find divergence
Locate the last confirmed (correct) block height.
4
Rollback state
Clear executed batches and operations after the divergence point.
5
Preserve snapshots
Verified historical balances and pairs up to the last correct block are retained.
6
Reprocess
Re-execute all blocks to rebuild current state.
Emergency stop
The sequencer includes a circuit breaker that activates automatically when unexpected failures or state mismatches are detected. When active, all new operations are rejected until the issue is resolved. This protects user funds from being processed during an inconsistent state.Transaction ordering
Operations are processed in strict FIFO (First In, First Out) order. The sequencer cannot reorder transactions within a batch, eliminating the possibility of sequencer-initiated front-running or MEV extraction.Audits
The smart contracts have been audited by Hashlock, an independent security firm.
For the full audit report and additional information, visit hashlock.com/audits/best-in-slot.