ALKANES: Smart Contracts on Bitcoin UTXOs

What is ALKANES?

ALKANES is an application layer built directly on Bitcoin where individuals or teams can deploy smart contracts to Bitcoin L1. ALKANES is one example of a metaprotocol, which is a set of rules and definitions to process block history in a blockchain system, to add additional features and concepts built on its data.

ALKANES is my conception of a metaprotocol project which inherits structures and design patterns from the very popular ordinals and runes metaprotocol projects, authored by Casey Rodarmor. From ordinals, we use the concept of the inscription envelope, but a more minimal variant of it, which we will simply call the witness envelope. We use the witness envelope, at minimum, to deploy *.wasm.gz files to the Bitcoin blockchain, after which they can be transacted against as smart contract programs, using any combination of inputs of value, data, and the context of the transaction itself.

With the *.wasm.gz file format of ALKANES smart contracts, we can build smart contracts in a language like Rust, and build contracts that are very much within the size constraints we must work within, when deploying to something like the Bitcoin blockchain. In fact, as an experiment, I , into the alkanes TypeScript repository here:

In this repository I have also written a docker-compose.yaml which provides a full regtest environment and supplementary database, usable to run the integration test mentioned above, but also to build applications! Indeed, it is possible to build applications that are even more expressive than what we have seen in traditional DeFi systems, using the combined power of LLVM and the paritytech wasmi interpreter / WebAssembly runtime, entirely on native Bitcoin L1.

What can an ALKANE do?

An alkane smart contract is very much a Bitcoin native construct. First and foremost, it is always a token, whether or not it actually does anything with its own balance sheet. It can hold a balance sheet of itself as well as other alkanes, the same that a UTXO can hold alkanes or runes. This idea actually resonated with me when Andre Cronje explained to me his thesis on DeFi many years ago, applied to his vision for YFI.

In simple terms: "make every contract an ERC20."

This happens to provide a consistent model for interoperability that helped DeFi take form, and I wanted this to exist as a primitive within ALKANES, bearing the improvement that a transfer of assets always invokes the code of the recipient, so we can always do everything in one transaction in the UX we build.

What else?

An alkane can:

• Check balances of alkanes


• Read/write to storage for the alkane


• Check how much fuel is left to execute code


• Access the transaction bytes of the Bitcoin transaction executing the alkane
  
  
  
  
  • If it is present, read one or more witness envelope structures present with the transaction, when we need to send a transaction with large payloads such as a zk proof, merkle proof, or quantum safe signature
    
  
  
  • Compute the address that the output will be spent to, or otherwise check the Bitcoin vmscript on the output that the output of some alkanes action will end up on, if we want to check for covenants, enforce conditions on spending, or other novel uses of OP_CAT even. Building on UTXOs mean we have the benefit of being able to extend Bitcoin scripting as we normally use it, and get the benefit of new opcodes as they occur, if they do.
  
  
  
  
  
  



• Access the entire block bytes which the current transaction is running within
  
  
  
  
  • Programmatically determine who the miner of the current block is (we may want to bribe this individual in our transaction, perhaps)
  
  
  
  
  
  



• 
  
  


• Act upon the transfer of value sent with the transaction, in terms of the combined balance sheet of alkanes spent into the action



• Access the ID for the alkane calling the current alkane, if they call each other



• Access the ID for the alkane executing code



• Call another alkane



• Delegate to another alkane (upgradeability, libraries)



• Call another alkane but prevent side effects



• Get the next sequence number, usable also if an alkane is created by an alkane in a transaction and its ID should be computed

I tried not to get too much fancier than this, since everything else should be doable in userspace.

Indexer

The indexer for ALKANES itself actually builds to WASM. So, it is true that the WASM VM for an alkane, is itself, built to WASM. The reason it was possible to build a metaprotocol that was deterministic and which meets the strict integrity requirements of a metaprotocol indexer built on top of a blockchain consensus model, is because we have something like metashrew, which is a generic metaprotocol indexer stack capable of running WASM programs expressing a metaprotocol.

Links

Software

Announcements