Forget indexers. Forget trust assumptions. This is what covenant-enforced token programmability actually looks like.
There is a recurring argument in Bitcoin discourse that goes something like this, Bitcoin doesn’t need tokens. It’s digital gold. Store of value. Leave the programmability to Ethereum.
That argument is getting harder to make.
Not because of hype, and not because of marketing. Because of cryptography, UTXO mechanics, and a carefully designed covenant protocol that puts token logic directly inside Bitcoin Script where miners validate it, consensus enforces it, and no third party can corrupt it.
That protocol is Covenant Attested Token (CAT).
Press enter or click to view image in full size
And understanding it requires unlearning almost everything you think you know about how Bitcoin tokens work.
The Problem with Every Other Bitcoin Token Protocol
Before we can appreciate what CAT does differently, we need to understand with what came before it.
BRC-20 tokens, Runes, Ordinals-based assets. Colored coins in their many forms. Every major Bitcoin token standard shares a common architectural flaw, they depend on off-chain indexers to determine whether a token transfer is valid.
Here’s what that actually means in practice.
When you send a BRC-20 token, the Bitcoin network itself has no idea what you’re doing. Miners see a standard transaction. The “token logic” lives entirely in the interpretation layer a separate piece of software that reads transaction data and decides whether a transfer is legitimate. Change the indexer, run a different implementation, or introduce a bug, and you get a different answer about who owns what.
This is not a minor implementation detail. It’s a fundamental trust assumption embedded in the protocol. You’re not trusting Bitcoin. You’re trusting whoever runs and maintains the indexer. And with multiple competing indexer implementations, disagreements about token balances are not theoretical they have happened.
There’s a deeper problem too. Because miners don’t understand these token rules, they happily mine invalid transfers. The network will never reject an “over-mint” transaction under an indexer-based model. Someone has to catch it after the fact. That someone is always a centralized party.
CAT Protocol was designed from the ground up to eliminate this class of problem entirely.
What CAT Protocol Actually Is
CAT stands for Covenant Attested Token. The name is precise these tokens are attested, validated by covenants. Not by indexers. Not by servers. By the Bitcoin consensus mechanism itself.
At its core, CAT is a UTXO-based token protocol that uses Bitcoin smart contracts specifically, covenant logic to enforce token rules at Layer 1. Every minting rule, every transfer constraint, every balance preservation requirement is embedded in Bitcoin Script and executed by miners when they validate transactions.
If a transaction violates the rules of a CAT token, the network rejects it, it doesn’t get mined.
This is the architectural breakthrough. Token validity is no longer a matter of interpretation. It’s a matter of consensus.
The protocol is built on the OP_CAT Layer, an extension to Bitcoin that enables the covenant mechanics necessary for this kind of programmability. The token state ownership, amount, lineage back to the genesis transaction is stored on-chain in UTXO contract state fields, verifiable by anyone with access to the blockchain.
Why CAT Is Fundamentally Different
Let’s be specific about what this architecture buys you.
No indexer required. The token ruleset is guaranteed by Bitcoin consensus. Both token data and logic reside on-chain. There is no off-chain third party involved in determining validity. The risk of indexer centralization, inconsistency, or manipulation simply does not exist.
Miner validation. When a transaction attempts to violate token rules say, minting beyond the allowed supply miners reject it. The invalid transaction never makes it into a block. This is the same security guarantee Bitcoin provides for BTC transfers, now extended to tokens.
Full on-chain state. Token balances, ownership records, minting history, and lineage back to the genesis transaction all live on-chain. Light clients can verify all of this independently.
Native Bitcoin security. CAT tokens inherit Bitcoin’s proof-of-work security model directly. There is no separate consensus mechanism, no additional validator set, no bridging trust assumption introduced by the token layer itself.
SPV compatibility. A CAT token transaction that is sufficiently deep in the blockchain can be verified by a light client a mobile wallet, for instance without trusting a full node or a centralized server. This mirrors how Bitcoin itself handles SPV verification. The implications for mobile-native Bitcoin applications are significant.
Cross-chain interoperability. The CAT protocol enables trust-minimized asset movement between blockchains, where users trust only the underlying chains themselves not bridges, not custodians, not multisig federations.
CAT20: Fungible Tokens with Programmable Minting
CAT20 is the fungible token standard within the CAT Protocol. Think of it as Bitcoin’s answer to ERC-20, but with a critical difference, the minting rules are not enforced by an indexer they’re enforced by a smart contract that miners execute.
Deploying a CAT20 token requires two transactions. The first is the genesis transaction, which embeds token metadata (name, symbol, decimals) in a CAT envelope using a specific byte sequence (0x636174 the ASCII encoding of "cat") that signals CAT Protocol participation. The second is the deploy transaction, which establishes the initial minter UTXOs.
Those minter UTXOs are the keys to the entire minting architecture. New tokens can only be created by spending a minter UTXO. The minter UTXO can generate additional minter UTXOs, enabling recursive minting. But crucially, the rules governing this process are programmed into the minter smart contract not into the protocol itself and not into an indexer.
This distinction creates extraordinary flexibility.
Open minting allows anyone to participate the contract specifies total supply and per-transaction limits, and enforces them without any permissioned party. Closed minting restricts issuance behind a signature requirement. Premine support lets issuers allocate initial tokens before opening minting to the public, by requiring issuer signatures only for the first mints and then removing that constraint. Fixed supply is achieved by ensuring the final mint transaction creates no new minter UTXOs once they’re gone, minting is provably terminated.
Parallel minting deserves special attention. In open minting scenarios, contention for a single minter UTXO would cause most mint transactions to fail. CAT20 addresses this by allowing a mint transaction to create multiple minter UTXOs a “concurrency” parameter. If N = 2, each mint doubles the number of available minter UTXOs, forming a tree structure rather than a chain. Contention drops dramatically as supply propagates.
Beyond the standard patterns, CAT20 supports arbitrary custom minting logic. Consider what becomes possible:
Tokens mintable only upon paying a specified amount of BTC to a given address
Tokens mintable only after a certain block height or timestamp
Proof-of-work minting require a computational puzzle solution, effectively mining the token
Tokens mintable only by holders of a different CAT token
Bitcoin-backed issuance the more BTC time-locked, the more tokens earned
None of these require protocol changes. None require a new indexer deployment. They’re just smart contract code, validated on-chain.
Transfer in CAT20 is equally principled multiple token inputs can be merged, single inputs can be split, and multiple token types can be transferred in a single transaction. The balance preservation invariant inputs must equal outputs is enforced by miners at the protocol level.
CAT721: NFTs That Actually Live on Bitcoin
CAT721 is the non-fungible token standard. Unlike CAT20, CAT721 tokens cannot be subdivided. Each token is unique, non-interchangeable, and this is the part that matters stores its full data on-chain immutably in Bitcoin transactions.
Read that again. Not a hash pointing to an IPFS URL. Not a reference to a centralized metadata server. The actual content.
Deploying a CAT721 collection uses the same two-transaction pattern as CAT20 genesis transaction embeds collection metadata, deploy transaction establishes minter UTXOs. The collection ID is derived from the genesis outpoint, giving every NFT in the collection an unambiguous cryptographic lineage to a single on-chain event.
When an individual NFT is minted, it receives its own CAT envelope containing all its metadata content, MIME type, encoding, and optional delegate fields. Each NFT within a collection is assigned a local ID unique within that collection. The global identifier takes the form collectionId:localId, constructed entirely from on-chain transaction data.
This architecture means provenance is in the protocol. It doesn’t rely on off-chain data. Any party present or future can independently verify which NFTs belong to which collection, who minted them, and what their content is, purely from the Bitcoin transaction history.
Compare this to the dominant NFT infrastructure of today, where “ownership” frequently means owning a token that points to a URL that may or may not still resolve in ten years. CAT721 is a fundamentally different claim: the content exists on Bitcoin, and Bitcoin’s permanence is its permanence.
Royalties are supported at the metadata level collection creators can specify a receiver address and percentage though enforcement is voluntary in the marketplace ecosystem rather than protocol-mandated.
Batch transfers allow multiple NFTs, across different collections, to be moved in a single transaction. The set of NFT inputs must equal the set of NFT outputs. The protocol maintains strict accounting.
Contract-Owned Tokens: The Composability Primitive
This section is worth slowing down for, because it’s where CAT Protocol’s potential compounds dramatically.
In standard CAT token usage, each token UTXO has an owner address corresponding to a private key. Spending the token requires a signature, exactly as with standard Bitcoin P2PKH outputs. Clean, familiar, simple.
But there’s a second ownership model contract hash ownership.
A token UTXO can be deposited to a contract hash the SHA256 hash of an output script. No private key corresponds to this address. No individual controls it. The contract controls it.
To transfer tokens locked in a contract, the transaction must include a neighboring input that spends a UTXO at the owner contract address. The contract, through covenant logic, can then inspect the entire transaction and enforce whatever rules it specifies before approving the token movement.
This is composability. And it’s the same primitive that made ERC-20 ecosystem so explosive.
Before ERC-20 contracts could own tokens, Ethereum had wallets. After, it had Uniswap, Compound, Aave, and every DeFi protocol that followed. The ability for contracts to programmatically custody and transfer tokens without human key management is not a marginal feature it’s what makes an entire class of applications possible.
CAT Protocol brings this to Bitcoin.
Consider what becomes buildable:
Automated Market Makers : liquidity pools holding two CAT20 tokens, with covenant logic enforcing price curves and balance invariants on every swap transaction.
Decentralized exchanges : order books or pool-based, where the protocol itself holds token custody and enforces settlement.
Lending protocols : smart contracts that accept CAT tokens as collateral, issue loan positions, and enforce liquidation when collateral ratios drop.
Staking contracts : token vaults that accept deposits, track time-weighted positions, and release rewards according to programmed schedules.
Escrow systems : two-party agreements where tokens are held by a contract until conditions are met, releasing to either party based on on-chain verification.
Treasury contracts : DAO treasuries that hold tokens and require multisig or governance vote to release them.
On-chain game economies: contracts that mint, distribute, and verify in-game asset ownership with Bitcoin-grade security.
Critically, CAT tokens do not need to know about the application contracts that will eventually use them. A token deployed today can be deposited into a contract developed years later by a completely different team. The documentation captures this precisely: CAT tokens are “infinitely extensible and interoperable with decentralized applications.” The contract doesn’t have to be known at mint time.
This is open-ended composability, native to Bitcoin.
Guard Architecture: The Engineering Layer Under the Composability
CAT Protocol implements a system of guard contracts that act as programmable transfer validators. Every token transfer passes through a guard contract that verifies the transaction satisfies the balance preservation requirements and other protocol rules.
Understanding guards matters because they represent a deliberate engineering trade-off between transaction complexity and transaction cost. CAT provides four guard variants, parameterized by three values:
TI_COUNT: maximum inputs the guard handles
TO_COUNT: maximum outputs the guard handles
GTT_COUNT: maximum distinct token types in a single transaction
The four variants map cleanly to use cases:
6_6_2–6 inputs, 6 outputs, 2 token types. The minimal footprint guard. Optimized for peer-to-peer transfers, simple swaps, and any scenario where minimizing fees matters most. Start here.
6_6_4–6 inputs, 6 outputs, 4 token types. Slightly larger, supports more complex multi-token swaps and simple DEX operations without blowing up transaction size.
12_12_2–12 inputs, 12 outputs, 2 token types. Scaled for batch operations airdrops, UTXO consolidation, payment splitters, multi-party transactions involving one or two token types.
12_12_4–12 inputs, 12 outputs, 4 token types. Maximum flexibility for complex DeFi scenarios where multiple token pools and contract interactions need to happen in a single transaction.
Both CAT20 and CAT721 support all four variants. The guard selection happens at the contract level when deploying. For developers using the SDK’s high-level functions, guard selection is handled automatically based on transaction requirements.
The principle is sound always use the smallest guard that satisfies your requirements. Over-engineering your guard selection inflates fees unnecessarily. Under-engineering it means transactions fail.
This modular guard architecture is an important design decision. By decoupling the balance validation logic from the token contract itself and offering it in configurable sizes, CAT Protocol avoids a common trap in smart contract design — forcing every user to pay for the worst-case transaction complexity. You pay for what you need.
Why Developers Should Care Now
The combination of properties described above amounts to something that hasn’t existed on Bitcoin before, a programmable economic substrate where token logic, ownership, validation, and composability are all native to the chain.
Consider the development surface that opens up.
Stablecoin protocols can issue CAT20 tokens backed by BTC collateral, with the peg mechanism enforced by minter contracts. No trusted oracle required for basic mechanics the on-chain BTC collateral is directly visible to the covenant.
Real-world asset tokenization can anchor asset ownership in Bitcoin’s security model. A tokenized treasury bond, a property deed, a trade finance instrument the token’s validity doesn’t depend on a startup’s servers staying online.
Bitcoin-native DeFi becomes buildable without the trust compromises that plague current Bitcoin DeFi approaches. Bridged assets, wrapped tokens, and custodial intermediaries introduce risk at every layer. CAT tokens skip those layers entirely.
Gaming economies with genuine digital scarcity where item ownership is verified by Bitcoin miners, not game company servers become architecturally sound rather than aspirational.
Social applications where content ownership, reputation scores, and membership credentials are held as CAT tokens gain the same security properties as Bitcoin itself.
The SPV compatibility of CAT tokens means mobile applications don’t require full node infrastructure to verify token authenticity. The verification path is the same one Bitcoin has used for light clients since Satoshi described it in the original whitepaper.
Real-World Trajectories
The applications closest to production viability are those that map most directly to existing financial infrastructure:
Decentralized exchanges are a natural first target. The guard architecture and contract-owned token model provide the core primitives needed for AMM pool contracts and token swaps. Developers building on CAT today are likely building DEX infrastructure.
Lending markets follow directly from the ability for contracts to hold collateral and enforce liquidation conditions. CAT20 tokens as collateral against BTC loans, with covenants enforcing the liquidation trigger, is technically within reach.
Prediction markets benefit from Bitcoin’s finality guarantees and the ability to encode outcome resolution logic in covenant contracts.
Cross-chain liquidity becomes more tractable with CAT’s trust-minimized bridge architecture. Moving assets between chains without custodial intermediaries, trusting only the chains themselves, is a qualitatively different security model than what most bridges offer today.
NFT-based access systems where CAT721 token ownership gates content, services, or community membership benefit from the permanence of on-chain metadata. The access credential doesn’t expire because a server went offline.
The Horizon
Bitcoin has spent fifteen years as an extraordinarily reliable, extraordinarily conservative store of value. That conservatism is a feature, not a bug the protocol’s stability is precisely what makes it trustworthy.
CAT Protocol doesn’t ask Bitcoin to become something else. It extends what Bitcoin already does UTXO validation, Script execution, proof-of-work consensus into the domain of programmable tokens and composable applications. The security guarantees don’t change. The trust model doesn’t change. What changes is the surface area of what you can build on top of it.
The guard architecture enables fee optimization without sacrificing programmability. The contract-owned token model enables DeFi composability without trusting intermediaries. The covenant-enforced minting rules enable arbitrary issuance logic without indexer gatekeepers. The SPV compatibility enables mobile-native applications without full node infrastructure.
Each of these is a solved problem in the CAT design. Not a roadmap item. Implemented, documented, and available to developers today.
Conclusion
The most important question is no longer whether Bitcoin can support tokens and sophisticated applications. CAT Protocol demonstrates that the real question is how far Bitcoin programmability can go when token logic, ownership, and validation become native properties of the chain itself enforced by miners, verifiable by light clients, composable by any contract that cares to interact with them.
Every UTXO with a CAT token in it is a programmable unit of value that inherits Bitcoin’s security guarantees and can be unlocked by covenant logic rather than just a private key. Every minter contract is a programmable policy engine that miners enforce without needing to understand token semantics. Every guard variant is a configurable transaction validator that optimizes for cost without sacrificing correctness.
Bitcoin protocol engineering has a long history of doing more with less. CAT Protocol follows that tradition. The primitives are minimal. The implications are not.
Technical references: CAT Protocol Overview · CAT20 Specification · CAT721 Specification · Contract-Owned Tokens · Guard Variants · SDK Documentation
Top comments (0)