Skip to main content
The Best in Slot (BiS) AMM is a non-custodial automated market maker built on BRC2.0. It uses BLS12-381 cryptography and Bitcoin batch settlement to deliver trustless DeFi on Bitcoin.

​
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: 
Deposit Order:

Bitcoin Address:
BLS Public Key:
Token Address:

By signing this message, you authorize the creation of a deposit order with the above parameters.

​
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: 
message = keccak256(pubkey) || nonce || op_type || params_hash
If a user loses access to their Bitcoin wallet, the associated smart wallet cannot be recovered. This is by design — the system is non-custodial and there is no recovery mechanism. Users must secure their private keys.

​
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:
TriggerCondition
Operation threshold500 or more pending operations in the queue
Withdrawal priorityAny pending withdrawal operations AND no currently pending batches
This ensures withdrawals are processed promptly while maintaining efficient batching for regular operations.

​
Compression

Batch data is compressed before inscription to minimize fees:
  1. Zstd compression (level 22, maximum) is attempted first.
  2. NADA encoding is used as fallback if it produces smaller output.
  3. A 1-byte prefix indicates the encoding: 0x01 = NADA, 0x02 = Zstd.
The envelope format inscribed on-chain: 
{ "p": "brc20-prog", "op": "t", "b": "<compressed_batch_data>" }

​
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. 
const P = bls12_381.G1.hashToCurve(msg_buf, {
  DST: 'BLS_SIG_BLS12381G1_XMD:SHA-256_SSWU_RO_NUL_'
});

​
Message format

Each operation’s signed message is constructed as: 
keccak256(pubkey) || nonce (4 bytes) || op_type (1 byte) || params_hash
For unwrap operations specifically: 
keccak256(pubkey) || nonce || 0x06 || keccak256(pkscript) || amount || fee

​
Signature aggregation

Individual signatures from multiple operations are aggregated into a single signature per batch: 
const aggregated_sigs = bls12_381.shortSignatures.aggregateSignatures(signatures);
const neg_aggregated_sigs = aggregated_sigs.negate();
The negated aggregated signature is submitted to the sequencer contract’s 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.
The wrap data includes:
  • 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:
keccak256(pubkey) || nonce || 0x06 || keccak256(pkscript) || amount || fee
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.
AspectCurrent statePlanned
Custody typeMultisigCommittee-based
SignersSubfrost team membersIndependent committee members
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

ComponentTrust assumption
UserHolds private keys, signs all operations
SequencerTrusted for liveness only, not custody. Cannot forge signatures or steal funds
BitcoinProvides finality and data availability
BRC-20 EVMExecutes state transitions deterministically
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.
AuditorScopeDateRating
HashlockBiS_Swap, bls12lib.sol & Uniswap Smart ContractsNovember 2025Secure
For the full audit report and additional information, visit hashlock.com/audits/best-in-slot.