Lately, Bitcoin Ordinals have garnered significant attention within the blockchain space. One alleged major drawback of Ordinals is its lack of support for smart contracts, compared to other token standards such as the Ethereum’s ERC-721.
We show how to add smart contract capabilities to Ordinals, broadening the spectrum of its use cases. Contrary to popular belief, not only are Ordinals compatible with smart contracts, they are actually perfectly suited for smart contracts.
As a showcase, we have developed a smart contract that enables permissioned ordinals. Compared to a regular/permissionless ordinal, each transfer needs to be approved and co-signed by an issuer.
Basic Idea
Bitcoin uses a UTXO (Unspent Transaction Output) model. Each UTXO consists of two fields:
- value: number of satoshis in this output
- script: a Bitcoin script that locks the output.
If the UTXO is inscribed as a non-fungible token (NFT) using 1Sat Ordinals, the value is 1 and the script controls how the token can be minted or transferred. Since the satoshi and script are in two orthogonal fields, an Ordinal token can be locked into any script. That means the token can be controlled by any smart contract.
Mint
As we introduced before, an Ordinal is inscribed in an “envelope” between Opcodes OP_FALSE OP_IF and OP_ENDIF.
OP_FALSE ensures the inscription script never enters the OP_IF branch and it is never executed. The whole inscription script can be regarded as a NOP and combined with other script without changing the latter’s execution.
In the case of sCrypt, it is prepended to the locking script that compiles from sCrypt smart contract¹. It does not change the behavior of the contract and can thus be safely combined with any contract.
<Inscription Script> <Locking Script>
Transfer
After the token is minted, its transfer is dictated by the smart contract, just like native bitcoins. Each transfer can move the token/satoshi into a new smart contract. Note there is no preceding inscription script in ensuring transfers, only when it is first inscribed.
<Locking Script>
Permissioned Ordinals
Most of ordinals today use Pay To Pubkey Hash (P2PKH) as locking script. When Alice wants to transfer an ordinal to Bob, she does not need permission from any third-party.
There are cases where each transfer has to be approved by the issuer, e.g., for legal compliance. When minting such an ordinal, we can use the following smart contract.
Besides a signature from the current owner at Line 26, which is a contract state at Line 10, a signature from the issuer is also needed at Line 28.
Since the contract is stateful, each transfer must ensure the satoshi is moved into the same contract, ensuring all subsequent transfers need issuer signature as well, not only the first transfer after minting. Note the leading inscription script is cut at the first transfer at Line 38.
Other Potential Use Cases
The orthogonality of Ordinal tokens and smart contracts means they are infinitely composable. There are numerous ways to combine them. We only list a few examples below:
- Ordinal lock: lock an ordinal utxo that can be unlocked by anyone by purchasing, or cancelled by the lister.
- OP-NS: use Ordinals Inscriptions backed by mini Proof-of-Work to create a fair-mint hierarchical naming system for the Bitcoin dataspace
- Atomic swap between ordinals and bitcoins: lock ordinals in a HLTC to allow trustless ordinal sales
- Cap supply: currently, BSV-20² allows more tokens minted than max supply in deployment. Using contract we can disallow such minting transactions on chain, instead of invalidating them off chain at indexers after the fact
- Blacklisting/whitelisting
- Freezing & recovery
[1] In fact, an inscription script can be inserted anywhere when the sCrypt smart contract is stateless. For example, it can be appended to the contract script. But appending does not work for stateful contracts. For it to work with any sCrypt contract, we put it at the very beginning as a convention.
[2] Fungible token standard based of 1Sat Ordinals.
