Filling BTC Orders
LI.FI intent supports Bitcoin orders. Filling Bitcoin orders is more complex than filling EVM orders. If you are interested in filling Bitcoin orders, reach out and we will assist you.
LI.FI intent supports a Bitcoin validation layer. However, filling Bitcoin swaps is technically more involved than filling EVM swaps. If you are already filling EVM swaps and are interested in filling BTC swaps, or if you want to add Bitcoin swaps to your app through LI.FI intent, reach out and we can get you onboarded.
To determine whether an order involves a Bitcoin transaction, check the orderDto.order.outputs[].token
field. If the token indicates Bitcoin, ensure the following conditions are met:
-
The first 30 bytes of the token should be
0x000000000000000000000000BC0000000000000000000000000000000000
. The 13th byte is0xBC
. -
The 31st byte indicates the number of confirmations required before the order can be verified on-chain.
0x00
and0x01
represent 1 confirmation.0x02
represents 2 confirmations.0x03
represents 3 confirmations, and so on.
-
The 32nd byte contains an address version identifier, which should be decoded as
uint8
.
If the transaction is directed to Bitcoin, the address (orderDto.order.outputs[].recipient
) will contain a relevant destination hash or witness, not the address itself. This value must be used along with the address version identifier – the 32nd byte of the token – to decode the address.
Version | Name | Encoding Scheme | Prefix | Hash Length |
---|---|---|---|---|
0 | Unknown | Ignore | ||
1 | P2PKH | Base58Check(00+PKH) | 1* | 20 |
2 | P2SH | Base58Check(05+SH) | 3* | 20 |
3 | P2WPKH | Bech32 | bc1q** | 20 |
4 | P2WSH | Bech32 | bc1q** | 32 |
5 | P2TR | Bech32m | bc1p** | 32 |
* Prefixes are determined by the encoding scheme.
** Part of the prefix – 1q/1p – is determined by the encoding scheme.
You can use the script below to get inspiration for how to decode the Bitcoin address from an output description.
Once the address is generated, create a Bitcoin transaction with at least one output that exactly matches the described output from the initiated order. The transaction can have any number of inputs and outputs, as long as one output precisely matches the one specified by the order’s output. This flexibility allows for batch filling, consolidation, and more.
If the calldata is set on the output description, the Bitcoin transaction needs a second output which is exactly the next output index after the output filling the order: