DEV Community: OPCAT Maxi

[Boost]

OPCAT Maxi — Sun, 14 Jun 2026 16:55:14 +0000

OPCAT Maxi

Jun 14

CAT Protocol: How Bitcoin Finally Got Native Smart Tokens

#bitcoin #opcat #blockchain #ai

12 min read

CAT Protocol: How Bitcoin Finally Got Native Smart Tokens

OPCAT Maxi — Sun, 14 Jun 2026 16:49:34 +0000

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

Bitcoin OP_CAT Use Cases Series #2: Merkle Trees

OPCAT Maxi — Sun, 23 Jun 2024 07:25:35 +0000

Following our series #1, we demonstrate how to construct and verify Merkle trees using OP_CAT.

In Bitcoin, Merkle trees are utilized as the data structure for verifying data, synchronization, and effectively linking the blockchain’s transactions and blocks together. The OP_CAT opcode, which allows for the concatenation of two stack variables, can be used with SHA256 hashes of public keys to streamline the Merkle tree verification process within Bitcoin Script. OP_CAT uniquely allows for the creation and opening of entries in Merkle trees, as the fundamental operation for building and verifying Merkle trees involves concatenating two values and then hashing them.

There are numerous applications for Merkle trees. We list a few prominent examples below.

Merkle proof
A Merkle proof is a cryptographic method used to verify that a specific transaction is included in a Merkle tree without needing to download the entire blockchain. This is particularly useful for lightweight clients and enhancing the efficiency of data verification.

Tree signature
A tree signature is a cryptographic method that enhances the security and efficiency of digital signatures using tree structures, particularly Merkle trees. Compared to regular Multisig, this approach is used to generate a more compact and private proof that a message or a set of messages has been signed by a specific key.

Zero-Knowledge Proof
STARK (Succinct Transparent Arguments of Knowledge) is a type of zero-knowledge proof system. STARKs are designed to allow a prover to demonstrate the validity of a computation to a verifier without revealing any sensitive information about the computation itself. If OP_CAT were to be added to Bitcoin, it could potentially enable the implementation of a STARK verifier in Bitcoin Script, with work already ongoing. This would allow for secure and private transactions on the Bitcoin network. Compared to pairing-based proof systems such as SNARK, STARK is considered to be more Bitcoin-friendly.

Implementation
The implementation of the merkle tree using sCrypt is trivial. The following code calculates the root hash of a merkle tree, given a leaf and its merkle path, commonly used in verifying a merkle proof.

/**
 * According to the given leaf node and merkle path, calculate the hash of the root node of the merkle tree.
*/
@method()
static calcMerkleRoot(
    leaf: Sha256,
    merkleProof: MerkleProof
): Sha256 {
    let root = leaf

    for (let i = 0; i < MERKLE_PROOF_MAX_DEPTH; i++) {
        const node = merkleProof[i]
        if (node.pos != NodePos.Invalid) {
            // s is valid
            root =
                node.pos == NodePos.Left
                    ? Sha256(hash256(node.hash + root))
                    : Sha256(hash256(root + node.hash))
        }
    }

    return root
}

Full code is at https://github.com/sCrypt-Inc/scrypt-btc-merkle.

A single run results in the following transactions:

Script versions
There are alternative implementations in bare scripts, like the one below. One significant advantage of using sCrypt for implementing merkle trees is its readability and maintainability. Scripts are often extremely hard to read and work on.

OP_TOALTSTACK
OP_CAT
OP_CAT
OP_TOALTSTACK
OP_CAT
OP_TOALTSTACK

<0x8743daaedb34ef07d3296d279003603c45af71018431fd26e4957e772df122cb>
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

...

Stay tuned for more OP_CAT use cases.

Smart Contract Programming Languages: sCrypt vs. Solidity

OPCAT Maxi — Fri, 05 Apr 2024 21:17:23 +0000

This article offers a comparison between two Web3 smart contract programming languages, sCrypt and Solidity, to help you decide which one you should use for building smart contracts in the Bitcoin or Ethereum Virtual Machine ecosystems, respectively.

Solidity
Solidity emerged as the first-ever programming language for smart contracts and remains the most extensively utilized language in the Web3 space due to its first-mover advantage. It serves as the primary language for developing applications today on Ethereum and
Ethereum Virtual Machine (EVM) compatible blockchains, including Binance Smart Chain and Tron.

sCrypt
sCrypt was developed with the aim of ensuring the utmost safety, security, and predictability in managing blockchain assets, while also equipping developers with the tools to create cutting-edge blockchain applications. Introduced 8 years following Solidity, sCrypt incorporated many lessons learned from the early years of Web3 application development, emphasizing the critical need for secure and reliable smart contracts. It is the primary smart contract language for Bitcoin Virtual Machine (BVM) based blockchains such as BTC, BSV, and MVC.

Overview: sCrypt vs. Solidity
Smart contracts control and manage billions of dollars’ worth of cryptocurrency and digital assets. Security flaws can lead to direct financial losses, particularly due to irreversible transactions and immutable code. Losses from hacks involving Solidity smart contracts have amounted to hundreds of millions of dollars over the years. These losses stem from a variety of vulnerabilities and attack vectors.

The Ethereum community has made significant efforts to enable developers to create secure smart contracts by providing security guidelines and compiling information on known attacks and vulnerabilities. However, despite these efforts, security issues persist, largely because the Solidity language inherently permits these vulnerabilities. In contrast, sCrypt effectively eliminates many of these security flaws right from the start.

sCrypt, being a modern language, learns from Solidity’s flaws. It adopts a distinctive approach in its design, focusing primarily on security and ensuring predictable behavior. The foundational principles of sCrypt were significantly influenced by analyzing prevalent Solidity vulnerabilities, leading to the development of a language specifically engineered with predictability and security as its primary objectives. sCrypt prioritizes security from the ground up. Its design was informed by a thorough review of the typical errors, vulnerabilities, and challenges encountered in smart contract development. The philosophy behind sCrypt emphasizes that if it’s possible to maintain functionality and expressiveness while greatly reducing the likelihood of human mistakes, such measures should be implemented at the language level.

Establishing the right mental frameworks for smart contracts and blockchain systems is crucial: complexity introduces a higher likelihood of bugs, leading to further complexity in attempts to fix those bugs. This cycle can trap us in a continuously escalating complexity spiral, as witnessed in Solidity. Tackling these challenges at the programming language level can prevent this compounding complexity.

Below is a high-level comparison between these two languages:

Decidability
sCrypt is considered decidable, since an sCrypt smart contract always terminates and halts in a finite number of steps, for any given input. Put simply: it is guaranteed that sCrypt contract execution will end.

Solidity supports unbounded loops, recursion, and dynamic function calls, which makes it impossible to decide if a Solidity smart contract will halt or not.

sCrypt disallows unbounded loops and recursion at language level. Surprisingly, this is achieved without sacrificing expressivity, meaning Bitcoin smart contracts are still Turing-Complete.

The fact that sCrypt is decidable ensures that developers (and their tools) can more straightforwardly understand and accurately predict how sCrypt contracts will behave, no matter what the input is. In many situations, particularly with high-stakes transactions or critical systems, this predictability is highly valued.

Decidability also allows for formal verification by complete static analysis of the entire call graph of a given smart contract. Formal verification is a popular method in security testing and auditing, using mathematical proofs to verify that specific properties of the contracts will consistently hold true or false under all conditions. Doing so to Solidity is incredibly difficult, due to the explosion of available paths.

Reentrancy
Reentrancy occurs when a smart contract makes a call to another contract, which then makes a call back to the original contract, effectively re-entering the initial logic. For instance, Contract A calls Contract B, waiting for a specific condition to be fulfilled before it updates its state. Meanwhile, Contract B calls back into Contract A. If your contract design isn’t meticulously crafted, reentrancy can cause your code to behave in unintended ways, whether due to a bug or as an exploit by a malicious entity. It could enable an attacker to execute multiple withdrawals before the contract updates its internal ledger, exposing the contract to various risks, including the potential for the total token balance to be siphoned off, as was infamously the case with the DAO hack.

Solidity permits reentrancy and has recently introduced an optional [noReentrancy] guard that developers can choose to implement or not. Ultimately, the responsibility is on the developers to use this feature.

In contrast, sCrypt does not permit reentrancy at all, eliminating this risk by design.

Overflows and underflows
In Solidity, overflows occur when a calculation exceeds the maximum value that can be stored, while underflows happen when a calculation falls below the minimum value. Such events can throw smart contracts into chaos, and attackers may deliberately trigger them in contracts that are poorly coded. Typically, this results in the contract becoming inoperable or being depleted of its tokens.

sCrypt guards against overflows and underflows by using only big numbers called bigint, a data type that can store integers with an arbitrarily large number of digits.

Learning Curve and Developer Tooling
sCrypt is an embedded Domain Specific Language (eDSL) based on TypeScript. It is strictly a subset of TypeScript, so all sCrypt code is valid TypeScript. TypeScript is chosen as the host language because it provides an easy, familiar language (JavaScript), but with type safety. There’s an abundance of learning materials available for TypeScript and thus sCrypt, including online tutorials, courses, documentation, and community support. This makes it relatively easy for beginners to start learning. It also has a vast ecosystem with numerous libraries and frameworks (e.g., React, Angular, Vue) that can simplify development and integration with Web2 applications.

Solidity presents a steeper learning curve, especially for those new to blockchain concepts. It requires a solid understanding of specific security practices and the Ethereum ecosystem. While there are growing resources for learning Solidity, including official documentation, tutorials, and courses, the pool is orders of magnitudes smaller compared to TypeScript.

Debugging Solidity code can prove to be difficult because of the limited availability of advanced debugging tools. This limitation hampers the ability to diagnose and fix issues, particularly in the case of complex contracts. sCrypt, being TypeScript, enjoys many modern debuggers such as in Visual Studio Code. It is supported by any TypeScript IDEs, including Visual Studio Code, WebStorm, Vim and Atom.

Pure
A pure function is a specific type of function that has the following characteristics:

_Deterministic Output: _The output of a pure function is solely determined by its input values. Given the same input, a pure function will always return the same output.
Stateless: A pure function does not maintain or require any internal state to compute their output.
_No Side Effects: _A pure function does not cause any observable side effects in the outside world. This means it does not modify any external state, global variables, or data outside its scope, nor does it depend on any external state. Pure functions align closely with mathematical functions like quadratic (y=ax²+bx+c) or trigonometric (y=sin(x)). They allow for greater predictability, easier testing, and more efficient code optimization by compilers.

All sCrypt functions declared as public are pure and boolean, evaluating to true or false. A function returning true will always return true, regardless of where, when, and how it is run. Its return is only determined by the calling transaction and arguments, which are both local. This means if a function is true when tested locally, it will be deemed true by miners when the enclosing transaction is broadcast. We do not even need to run a local node (e.g., regtest) to test it, since it can be evaluated without accessing a miner network.

In Solidity, functions are impure and capable of interacting with the blockchain through various actions, including reading from and altering the contract’s state, transferring ether, and invoking other contracts. The only exception is functions marked as pure. This impurity and unpredictability can make the code harder to test, debug, and reason about. Impure functions that alter contract states or perform transactions can be exploitable points for attackers.

Postconditions
Postconditions in programming are conditions or predicates that must hold true immediately after the execution of a program or a specific block of code, such as a function or method. They are a key concept in the design by contract methodology, where they are used to specify and document the expected state of a system after a piece of code executes. Postconditions help in ensuring that a program behaves as expected and can be used for debugging, testing, and formal verification purposes.

Let’s consider a function that increments a given number by one. To illustrate postconditions in JavaScript, a simple check is included after the function’s execution to ensure the postcondition holds true.

function incrementByOne(number) {
  const result = number + 1;
  return result;
}

// Function to check postcondition
function checkPostcondition(input, output) {
  if (output !== input + 1) {
    throw new Error('Postcondition failed: The output is not one greater than the input.');
  }
}

// Example usage
const inputNumber = 5;
const incrementedNumber = incrementByOne(inputNumber);

// Check the postcondition
checkPostcondition(inputNumber, incrementedNumber);

console.log('Incremented number:', incrementedNumber);

In the context smart contract, postconditions protect developers and users from bugs and abuse.

In sCrypt contracts with state update, the new state has to be passed in when the calling transaction is constructed off chain, which is verified in the smart contract on chain. We are guaranteed the contract enters the expected and correct new state after the call.

In Solidity, only the action of how a state is updated is specified. The new state is generally not passed in and one could only hope the contract is updated to the new expected state, making it unpredictable and error-prone.

sCrypt verifies, while Solidity computes. The former is more secure and reliable.

Composition over inheritance
sCrypt emphasizes using composition instead of inheritance. This approach implies that sCrypt smart contracts do not engage in inheritance as observed in languages such as Solidity. Consequently, there’s no need to navigate through intricate class hierarchies or deal with contracts that carry implicit behaviors from their ancestors. sCrypt mandates explicitness and deliberate composition in its design. Without the concept of inheritance, developers are required to clearly define the actions of their code. This characteristic enhances the predictability and transparency of contracts and simplifies the audit process.

The Complete Guide to Full Stack Bitcoin SV Development

OPCAT Maxi — Thu, 28 Mar 2024 17:09:25 +0000

In this guide, you’ll learn a web3 tech stack that will allow you to build full stack decentralized apps on the Bitcoin SV blockchain. We will walk through the entire process of building a full stack decentralized Tic-Tac-Toe, including:

Write a smart contract.
Deploy the contract
Add a front-end (React)
Integrate Yours wallet

By the end, you will have a fully functional Tic-Tac-Toe App running on Bitcoin.

What we will use

Let’s go over the main pieces we will be using and how they fit into the stack.

1 - sCrypt Framework

sCrypt is a TypeScript framework to develop smart contracts on Bitcoin. It offers a complete tech stack:

the sCrypt language: an embedded
Domain Specific Language
(eDSL) based on TypeScript, which allows developers to write
smart contracts directly in TypeScript. Developers don’t have
to learn a new Web3 programming language like Solidity, and can
reuse their favorite tools, like IDEs and NPM.
library (scrypt-ts):
a comprehensive and concise library
designed for client-side JavaScript applications, such as
React, Vue, Angular, or Svelte, to interact with the Bitcoin SV
Blockchain and its ecosystem.
sCrypt CLI: CLI to
easily create, compile and publish sCrypt
projects. The CLI provides best practice project scaffolding.

2. Yours Wallet

Yours Wallet is an open-source digital wallet for BSV and 1Sat Ordinals that enables access to decentralized applications developed on Bitcoin SV. Yours Wallet generates and manages private keys for its users in a non-custodial manner, ensuring that the users have full control over their funds and transactions. These keys can be utilized within the wallet to securely store funds and authorize transactions.

3. React

React.js, often simply referred to as React, is a JavaScript library developed by Facebook. It’s primarily used for building user interfaces (UIs) for web applications. It simplifies the process of building dynamic and interactive web applications and continues to be seemingly dominating the front-end space.

What we will Build

We will build a very simple Tic-Tac-Toe game on chain. It uses the Bitcoin addresses of two players (Alice and Bob respectively) to initialize a smart contract. They each bet the same amount and lock it into the contract. The winner takes all bitcoins locked in the contract. If no one wins and there is a draw, the two players can each withdraw half of the money. Tic-Tac-Toe, the age-old game of strategy and skill, has now found its way onto the blockchain thanks to the power of sCrypt.

Prerequisites

1 - Install node.js and npm (node.js ≥ version 16)
2 - Install Git
3 - Yours wallet Chrome extension installed in your browser
4 - Install sCrypt CLI
npm install -g scrypt-cli

Getting Started

Let’s simply create a new React project.

Firstly let’s create a new React project with TypeScript template.

npx create-react-app tic-tac-toe --template typescript

Then, change the directory to the tic-tac-toe project directory and also run the init command of the CLI to add sCrypt support in your project.

cd tic-tac-toe npx scrypt-cli@latest init

Tic-tac-toe Contract
Next, let’s create a contract at src/contracts/tictactoe.ts:

import {
    prop, method, SmartContract, PubKey, FixedArray, assert, Sig, Utils, toByteString, hash160,
    hash256,
    fill,
    ContractTransaction,
    MethodCallOptions,
    bsv
} from "scrypt-ts";

export class TicTacToe extends SmartContract {
    @prop()
    alice: PubKey;
    @prop()
    bob: PubKey;
    @prop(true)
    isAliceTurn: boolean;
    @prop(true)
    board: FixedArray<bigint, 9>;
    static readonly EMPTY: bigint = 0n;
    static readonly ALICE: bigint = 1n;
    static readonly BOB: bigint = 2n;

    constructor(alice: PubKey, bob: PubKey) {
        super(...arguments)
        this.alice = alice;
        this.bob = bob;
        this.isAliceTurn = true;
        this.board = fill(TicTacToe.EMPTY, 9);
    }

    @method()
    public move(n: bigint, sig: Sig) {
        // check position `n`
        assert(n >= 0n && n < 9n);
        // check signature `sig`
        let player: PubKey = this.isAliceTurn ? this.alice : this.bob;
        assert(this.checkSig(sig, player), `checkSig failed, pubkey: ${player}`);
        // update stateful properties to make the move
        assert(this.board[Number(n)] === TicTacToe.EMPTY, `board at position ${n} is not empty: ${this.board[Number(n)]}`);
        let play = this.isAliceTurn ? TicTacToe.ALICE : TicTacToe.BOB;
        this.board[Number(n)] = play;
        this.isAliceTurn = !this.isAliceTurn;

        // build the transation outputs
        let outputs = toByteString('');
        if (this.won(play)) {
            outputs = Utils.buildPublicKeyHashOutput(hash160(player), this.ctx.utxo.value);
        }
        else if (this.full()) {
            const halfAmount = this.ctx.utxo.value / 2n;
            const aliceOutput = Utils.buildPublicKeyHashOutput(hash160(this.alice), halfAmount);
            const bobOutput = Utils.buildPublicKeyHashOutput(hash160(this.bob), halfAmount);
            outputs = aliceOutput + bobOutput;
        }
        else {
            // build a output that contains latest contract state.
            outputs = this.buildStateOutput(this.ctx.utxo.value);
        }
        if (this.changeAmount > 0n) {
            outputs += this.buildChangeOutput();
        }
        // make sure the transaction contains the expected outputs built above
        assert(this.ctx.hashOutputs === hash256(outputs), "check hashOutputs failed");
    }

    @method()
    won(play: bigint): boolean {
        let lines: FixedArray<FixedArray<bigint, 3>, 8> = [
            [0n, 1n, 2n],
            [3n, 4n, 5n],
            [6n, 7n, 8n],
            [0n, 3n, 6n],
            [1n, 4n, 7n],
            [2n, 5n, 8n],
            [0n, 4n, 8n],
            [2n, 4n, 6n]
        ];
        let anyLine = false;
        for (let i = 0; i < 8; i++) {
            let line = true;
            for (let j = 0; j < 3; j++) {
                line = line && this.board[Number(lines[i][j])] === play;
            }
            anyLine = anyLine || line;
        }
        return anyLine;
    }

    @method()
    full(): boolean {
        let full = true;
        for (let i = 0; i < 9; i++) {
            full = full && this.board[i] !== TicTacToe.EMPTY;
        }
        return full;
    }

}

Properties
The Tic-Tac-Toe contract features several essential properties that define its functionality:

1 - Alice and Bob: Public keys of the two players.
2 - is_alice_turn: A boolean flag indicating whose turn it is
to play.
3 - board: A representation of the game board, stored as a
fixed-size array.
4 - Constants: Three static properties defining game symbols
and empty squares.

Constructor

constructor(alice: PubKey, bob: PubKey) {
        super(...arguments)
        this.alice = alice;
        this.bob = bob;
        this.isAliceTurn = true;
        this.board = fill(TicTacToe.EMPTY, 9);
    }

Upon deployment, the constructor initializes the contract with the public keys of Alice and Bob. Additionally, it sets up an empty game board to kickstart the game play.

Public methods
Each contract must have at least one public @method. It is denoted with the public modifier and does not return any value. It is visible outside the contract and acts as the main method into the contract (like main in C and Java).

The public method in the contract is move(), which allows players to make their moves on the board. This method validates the moves, checks the player's signature, updates the game state, and determines the outcome of the game.

Signature verification

Once the game contract is deployed, anyone can view and potentially interact with it. We need an authentication mechanism to ensure only the desired player can update the contract if it’s their turn. This is achieved using ditigal signatures.

Only the authorized player can make a move during their turn, validated through their respective public key stored in the contract.

// check signature `sig`
let player: PubKey = this.isAliceTurn ? this.alice : this.bob;
assert(this.checkSig(sig, player), `checkSig failed, pubkey: ${player}`);

Non-Public methods

The contract includes two non-public methods, won() and full(), responsible for determining whether a player has won the game and if the board is full, leading to a draw.

Tx Builder: buildTxForMove

Bitcoin transaction can have multiple inputs and outputs. We need to build a transaction when calling a contract.

Here, we have implement a customize transaction builder for the move() method as below:

static buildTxForMove(
    current: TicTacToe,
    options: MethodCallOptions<TicTacToe>,
    n: bigint
  ): Promise<ContractTransaction> {
    const play = current.isAliceTurn ? TicTacToe.ALICE : TicTacToe.BOB;
    const nextInstance = current.next();
    nextInstance.board[Number(n)] = play;
    nextInstance.isAliceTurn = !current.isAliceTurn;
    const unsignedTx: bsv.Transaction = new bsv.Transaction().addInput(
      current.buildContractInput(options.fromUTXO)
    );
    if (nextInstance.won(play)) {
      const script = Utils.buildPublicKeyHashScript(
        hash160(current.isAliceTurn ? current.alice : current.bob)
      );
      unsignedTx.addOutput(
        new bsv.Transaction.Output({
          script: bsv.Script.fromHex(script),
          satoshis: current.balance,
        })
      );
      if (options.changeAddress) {
        unsignedTx.change(options.changeAddress);
      }
      return Promise.resolve({
        tx: unsignedTx,
        atInputIndex: 0,
        nexts: [],
      });
    }
    if (nextInstance.full()) {
      const halfAmount = current.balance / 2;
      unsignedTx
        .addOutput(
          new bsv.Transaction.Output({
            script: bsv.Script.fromHex(
              Utils.buildPublicKeyHashScript(hash160(current.alice))
            ),
            satoshis: halfAmount,
          })
        )
        .addOutput(
          new bsv.Transaction.Output({
            script: bsv.Script.fromHex(
              Utils.buildPublicKeyHashScript(hash160(current.bob))
            ),
            satoshis: halfAmount,
          })
        );
      if (options.changeAddress) {
        unsignedTx.change(options.changeAddress);
      }
      return Promise.resolve({
        tx: unsignedTx,
        atInputIndex: 0,
        nexts: [],
      });
    }
    unsignedTx.setOutput(0, () => {
      return new bsv.Transaction.Output({
        script: nextInstance.lockingScript,
        satoshis: current.balance,
      });
    });
    if (options.changeAddress) {
      unsignedTx.change(options.changeAddress);
    }
    const nexts = [
      {
        instance: nextInstance,
        atOutputIndex: 0,
        balance: current.balance,
      },
    ];
    return Promise.resolve({
      tx: unsignedTx,
      atInputIndex: 0,
      nexts,
      next: nexts[0],
    });
  }

Integrate Front-end (React)

After we have written/tested our contract, we can integrate it with front-end so that users can play our game.

First, let’s compile the contract and get the contract artifact json file by running the command below :

npx scrypt-cli@latest compile

You should see an artifact file tictactoe.json in the artifacts directory. It can be used to initialize a contract at the front end.

import { TicTacToe } from './contracts/tictactoe';
import artifact from '../artifacts/tictactoe.json';

TicTacToe.loadArtifact(artifact);

Install and Fund Wallet

Before deploying a contract, we need to connect a wallet first. We use Yours Wallet, a MetaMask-like wallet.

After installing the wallet, click the settings button in the upper right corner to switch to testnet. Then copy your wallet address and go to our faucet to fund it.

Connect to wallet

We call requestAuth() to request to connect to the wallet. If the request is approved by the user, we now have full access to the wallet. We can, for example, call getDefaultPubKey() to get its public key.

const walletLogin = async () => {
    try {
      const provider = new DefaultProvider({
          network: bsv.Networks.testnet
      });
      const signer = new PandaSigner(provider);
      signerRef.current = signer;

      const { isAuthenticated, error } = await signer.requestAuth()
      if (!isAuthenticated) {
        throw new Error(error)
      }
      setConnected(true);
      const alicPubkey = await signer.getDefaultPubKey();
      setAlicePubkey(toHex(alicPubkey))
      // Prompt user to switch accounts
    } catch (error) {
      console.error("pandaLogin failed", error);
      alert("pandaLogin failed")
    }
};

Initialize the contract

We have obtained the contract class Tictactoe by loading the contract artifact file. When a user clicks the start button, the contract is initialized with the public keys of two players alice and bob. The public key can be obtained through calling getDefaultPubKey() of Signer.

The following code initializes the contract.

const [alicePubkey, setAlicePubkey] = useState("");
const [bobPubkey, setBobPubkey] = useState("");
...
const startGame = async (amount: number) => {
  try {
    const signer = signerRef.current as PandaSigner;
    const instance = new TicTacToe(
        PubKey(toHex(alicePubkey)),
        PubKey(toHex(bobPubkey))
      );
    await instance.connect(signer);

  } catch(e) {
    console.error('deploy TicTacToe failes', e)
    alert('deploy TicTacToe failes')
  }
};

Call the contract

Now we can start playing the game. Every move is a call to the contract and triggers a change in the state of the contract.

const { tx: callTx } = await p2pkh.methods.unlock(
    (sigResponses: SignatureResponse[]) => findSig(sigResponses, $publickey),
    $publickey,
    {
        pubKeyOrAddrToSign: $publickey.toAddress()
    } as MethodCallOptions<P2PKH>
);

After finishing with the front-end you can simply run :
npm start

You can now view it at http://localhost:3000/ in your browser.

Conclusion

Congratulations! You have just built your first full stack dApp on Bitcoin. Now you can play tic-tac-toe or build your favorite game on Bitcoin. Now would be a good time to pop some champagne if you haven’t already :).

One session of play can be viewed here:

https://youtu.be/l65Ha5AmKjk

All the code can be found at this github repo.

By default, we deploy the contract on testnet. You can easily change it to mainnet.

How to Become a BSV Blockchain Developer in 2024

OPCAT Maxi — Thu, 28 Mar 2024 16:16:59 +0000

In this rapidly growth of blockchain technology, developers play a pivotal role in shaping the future of decentralized systems. Among all the blockchain platforms, Bitcoin SV (BSV) stands out as a powerful Blockchain offering scalability, security, and stability. As we venture into 2024, the demand for skilled BSV blockchain developers continues to surge. If you’re excited and ready to dive into this exciting field, this comprehensive guide will show you the path to become a proficient BSV blockchain developer.

Understanding the BSV Ecosystem:

Before delving into the specifics of BSV development, it’s essential to grasp the fundamentals of the BSV ecosystem. BSV, short for Bitcoin Satoshi Vision, emerged as a result of a contentious hard fork from the Bitcoin Cash (BCH) blockchain. It upholds the original vision outlined in Satoshi Nakamoto’s whitepaper, emphasizing large block sizes and low fees to enable scalable transactions and data storage so that enterprises application can be build on top of blockchain.

Understand Basics :

BSV Academy - Bitcoin Theory Bitcoin Theory covers the design of Bitcoin as a system as prescribed by Satoshi Nakamoto.
BSV Academy - Bitcoin Essentials Bitcoin essentials covers Hash Functions, Merkle tree, Digital Signatures e.t.c.
Learnmeabitcoin - A very useful and comprehensive resources to understand how bitcoin (bsv) actually work.

Smart Contracts

sCrypt : sCrypt is an embedded Domain Specific Language (eDSL) based on TypeScript for writing smart contracts on Bitcoin SV. sCrypt is very powerful as Smart contracts on Bitcoin are based on the UTXO model, which makes bsv blockchain scale.
docs : A comprehensive documentation to learn sCrypt.
Boilerplate : Sample sCrypt Smart Contract codes along with tests with dozens of contract written already.

Developer Resources

A list of resources, tools, libraries, and projects related to the Bitcoin SV can be found here. Below are some of the resources :

sCrypt - ord : 1sat Ordinals library
DartSV : A dart library for interacting with bitcoin network.
JungleBus : is a powerful, low-level indexer to power lightweight Bitcoin data sets.
Bitcoin class with satoshi : A very useful youtube channel to learn sCrypt.

Communities

Telegram
Discord
Slack
X(twitter)
Reddit

Continuous Learning:

The field of blockchain technology evolves at a rapid pace, necessitating a commitment to lifelong learning. Engage with the BSV community through forums, meetups, and online resources to stay updated on industry trends.

Career and Opportunities:

As a BSV blockchain developer, you’ll find a wealth of career opportunities across various sectors in the eco - system. Whether you aspire to work for established enterprises, startups, or embark on entrepreneurial ventures, the demand for BSV expertise continues to grow exponentially.

Bsv blockchain jobs

Conclusion:

Becoming a proficient BSV blockchain developer requires dedication, curiosity, and a willingness to continue learning. By mastering sCrypt, leveraging BSV libraries and frameworks, and staying informed about the latest protocols and tools, you’ll position yourself as a valuable asset in the blockchain industry. As we navigate the transformative landscape of decentralized technology, seize the opportunity to leave your mark as a skilled BSV blockchain developer in 2024 and beyond.

Tag me if you build something great.