Programmable Coins

My article for the This Week in Chia (TWIC) Special Edition distributed at Chia Toronto 2026

As Bitcoin got popular, people realized blockchains could be used for more than just transfers - they could be a layer where advanced logic is trustlessly executed. This led to Ethereum, where, apart from user accounts, there are on-chain contracts - special addresses where you can send money and/or instructions and custom programs are executed. These programs are public, have persistent storage, and are allowed to send ether and/or instructions to other addresses as well.

The release of Ethereum opened up a new era of digital finance - but something got lost along the way, and it’s not clear if the choice was intentional. By defining accounts in a more rigid way, Ethereum got its design to be much closer to the current banking system, but lost some of the properties that made Bitcoin interesting, as value was now indirectly controlled by logic through contracts.

This brings us to this essay’s topic, Chia. Unlike Ethereum, Chia’s architecture extends Bitcoin in a way that allows for programs with arbitrary logic to run (without using ‘accounts’). There are many things that make Chia a unique blockchain, but this is the one I constantly find myself in awe of - its architecture allows for truly programmable money.

A quick intro to this architecture, the Coin Set model, is in order. Imagine you’re at the grocery store and need to pay $7 for groceries with a $10 bank note. The cashier would take your $10 and give you 3 $1 bank notes as change.

Let’s now introduce a twist: what if you wanted to make digital bank notes (or, in Coin Set terms, coins)? For one, there’s no reason to have denominations - a bank note can have any value whatsoever. Another foundational idea - which will sound a bit counter-intuitive, but will hopefully make sense shortly - is that bank notes can only be spent once. But how do you ‘spend’ a digital bank note? A transfer is a very specific case - the more general case is splitting. So, in the scenario above, you’d spend your $10 coin (starting to use Chia terminology) and split it into a $7 coin (for the cashier/store) and a $3 coin (your coin).

It’s easy to get from the example above to programmable money - just make every coin be able to contain a program (called a puzzle) that dictates what happens when it is spent. In practice, information is given to the coin when it’s spent in the form of a solution (list of values) for the puzzle (it’s a nice nomenclature, isn’t it?).

So, the Chia blockchain keeps track of a bunch of coins of arbitrary values, each of which can be spent once by providing a solution. Each coin’s puzzle then generates a list of actions - they come in the form of what we call side-effects (e.g., create a new coin with this puzzle and value, reserve this value as a transaction fee, etc.) or assertions about the outside world (e.g., at least this block height has been reached).

This will all seem a bit complicated at first - you can probably understand why Bitcoin launched with a simpler set of instructions. But the flexibility of Chia’s puzzles, as well as the many possible types of output conditions, can lead to really smart coins.

One of the first puzzles for which there’s no Bitcoin equivalent are singletons. Chia’s pooling protocol needed something unique on the Chia blockchain that can be spent more than one time. But how do you make coins keep an identity if they can only be spent once? The solution is quite elegant: you enforce certain restrictions while checking that the restrictions have been enforced in the past. In a singleton’s case, every singleton will only create exactly one designated descendant coin (except for melting, which is besides the point). Every singleton coin checks that it was either created by the launcher (a coin with a unique id that ‘launches’ the singleton lineage) or by a singleton with the same launcher. A nice way to think about this is that a valid singleton carries a baton coming all the way from the launcher - for every spend, the layer checks the baton is authentic and passes it to a new coin. With these rules, you can be sure that a singleton that is being spent is truly part of the lineage originally created by the launcher. The singleton code was later refined and, as you’ll see, used in many other areas.

With checks such as the singleton lineage one, it makes sense to think of puzzles in terms of layers. A singleton layer is always the outermost layer, as it has to place restrictions on all the output conditions in order for uniqueness to truly be enforced. Its inner layer would then contain pooling-specific logic. An NFT has a singleton outer layer as well, with inner layers for keeping track of metadata, enforcing royalties, and custody.

This idea of enforcing a set of rules, then checking your parent (the coin that created you) to have the same logic is really powerful, as it means you enforce rules since creation (since your parent would check its parent, which would check its parent’s parent, and so on). In Bitcoin terms, these are known as covenants, and also allow colored coins - which Chia users also know as Chia Asset Tokens, or CATs.

The concept behind CATs is simple: instead of ensuring uniqueness (like the singleton layer does), you ‘mark’ some mojos (the equivalent of wei/sats) for a specific use case. This can be done with a CAT outer layer that ensures all created coins retain the original mark, and that the total value of CATs that were spent equals the total value of CATs that were created (in Chia, you can spend two coins to combine them - only one of them would be the parent of the new coin). The mark is a hash of a program that’s unique to each CAT - the TAIL, which controls when (and which) of these rules can be broken. Currently, most CATs are single issuance, so the only moment when normal Chia can be marked (and totals mismatch) is when the CATs are initially minted. But it’s interesting to think each CAT contains some small value (by convention, each unit currently has 1000 mojos, so a CAT’s smallest denomination is 0.001) - and some more advanced TAILs allow the mark to be removed and for this value to become normal Chia in special cases (TibetSwap’s liquidity tokens are a good example - see below).

At this point, you might be wondering how CATs manage to coordinate (with respect to total value spent/created inside a block) without the help of Chia consensus, which only cares about mojos, no matter if they’re marked or not. Chia’s creators were wise enough to come up with announcements, which coins can create and assert through their output conditions. Announcements are how coins exchange data - they allow CATs to coordinate through rings where totals are enforced.

The design of offers - our next puzzle stop - also provides a nice way of understanding announcements. Imagine you want to exchange 10,000 Chia for 1 Marmot Coin (a CAT on the Chia blockchain). How do you make this a trustless atomic swap (each swap gives an asset and receives the other, with all the transfers being coupled - they either all get executed or none does) in a single transaction?

Imagine Alice and Bob want to make this exchange with two teleporters. In both, they put their assets, which they can withdraw at any time before they are teleported. These teleporters are automatic: Alice’s XCH will rematerialize in Bob’s teleporter only if Bob’s Marmot Coin rematerializes in Alice’s teleporter at the same time, and the other way around. The exchange only happens when both assets are exchanged at the same time. If you assume that’s possible and there’s no deadlock, you have Chia offers: a settlement puzzle (the teleporter) creates an announcement containing the asset being sent, amount, and destination (equivalent to the ‘rematerialization’ part) and sends the said value to the recipient. By having each party use the settlement puzzle for their asset and assert an announcement to ensure the other party sent their funds, the exchange can take place trustlessly - and in a single transaction!

With these examples, I hope I’ve shown you two things. First, the puzzles powering everyday transactions on Chia are incredibly interesting and well-thought. Second, designing primitives for the Coin Set model is tricky - it’s not intuitive, and sometimes the tricks employed can take a while to understand (let alone invent). At this point, you’d be right to ask if advanced applications can exist at all in this environment. And you’d not be alone - time for another short story.

Almost 4 years ago, the community was split on the matter. As in any early DeFi ecosystem, everyone wanted an Automated Market Maker (AMM), a kind of public, automated trading bot, to exist. However, at least one big ecosystem team has been working on creating one for over a year, and launch was not in sight for months. I’d say over 50% of the community thought an AMM would not be possible on Chia back then. This is also the moment when I’d say I made a name for myself in the community - after several small projects, I launched TibetSwap, Chia’s first AMM.

Personally, I’d say creating complex protocols brings an additional factor of being aware of the pieces you have, as well as knowing when and how to combine them versus creating new ones. The former was especially difficult; TibetSwap made use of the singleton layer, CATs (including custom TAILs), offers, as well as a prefarm custody puzzle in a time when documentation was still very sparse and LLMs couldn’t help at all. But it pushed through and demonstrated once and for all that you could, after all, have complex apps live on-chain. Other complex apps have been launched after, including, but not limited to, warp[.]green (a Chia-Base/Ethereum bridge, which I’ve also designed), CircuitDAO (on-chain collateralized loans), and others.

So, what’s next in terms of Chia decentralized apps? I think the most important improvements come in two areas: iterating faster (tooling) and expanding what can be done (on-chain primitives). On the developer tools side, Rigidity spearheaded two initiatives that I believe make development a lot better: a Rust SDK (chia-wallet-sdk) and a new programming language for on-chain apps, Rue. I’ve had a chance to try both of them out (and even shape them a bit), and I would say each makes development much easier - helping with writing drivers, testing, readability, and debugging.

On the on-chain part itself, I’ve been working on something over the past year(s) that actually stemmed from writing an unreleased version of TibetSwap - a v2.5 if you will. It turns out most dApps can have the same structure - namely, a singleton is the ‘brain’ that contains all the logic and tracks some state. For example, a TibetSwap pair would track things like liquidity and the amount of tokens in the reserve; the singleton code contains the logic of how those change when someone swaps, adds, or removes liquidity - the reserves themselves (coins holding XCH/CATs) just listen to the singleton’s ‘instructions’ via announcements.

This abstraction came to be known as the action layer - it’s kind of a framework where I’ve written the glue holding different actions (logic behind user-called functions, such as adding liquidity), state, and, optionally, reserves. It has, at this point, been thoroughly reviewed and optimized. I think it doesn’t just make it so developers have less code to write, but also provides a way of splitting the logic into chunks, much like Solidity contracts can have different external functions.

This is more thoroughly presented in CHIP-0051, and goes hand-in-hand with slots. In short, slots are a way for dApps to leave ‘post-it notes’ they can revisit in the future - it’s a way for applications to have access to arrays and hashmaps (or mappings, for those familiar with Solidity). Even more, you can see them as a way of allocating memory - meaning you can implement other structures as well. Compared to the app state, you only reveal slots when the app needs them - so, if your app has 100,000 entries in a list built with slots, the values don’t get revealed every time your app’s singleton is spent, which reduces costs a lot - even making some new types of apps feasible.

I am very excited with all the new additions, and am currently in the late stages of building 3 new decentralized applications: a decentralized naming system (XCHandles), a CAT details registry (CATalog), and a reward distribution system (for NFTs, dynamic lists controlled by someone, and CATs). I hope that, by now, you can appreciate that making apps on Chia is not particularly easy - but I think we’re entering an era where we’ll see another bloom of complex dApps, with these new tools giving us the capabilities to truly be able to port anything that’s available on other chains and bake it directly into coins.