Few people know Bitcoin Cash has smart contracts that are easy to write. The language is called @CashScriptBCH . It has been around since 2019, it looks like Solidity, and it compiles down to the native scripting system that already runs on Bitcoin Cash. No sidechain, no virtual machine bolted on top, no bridge holding your money while the contract executes. Here is a complete escrow contract: pragma cashscript ^0.14.0; contract TransferWithTimeout(pubkey sender, pubkey recipient, int timeout) { function transfer(sig recipientSig) { require(checkSig(recipientSig, recipient)); } function timeout(sig senderSig) { require(checkSig(senderSig, sender)); require(tx.time >= timeout); } } Two ways to spend. The recipient can take the money whenever they sign. The sender can take it back after the timeout. That is a working escrow, and it fits in a screenshot. WHAT MAKES IT DIFFERENT FROM SOLIDITY CashScript borrows Solidity's syntax and almost none of its problems. On Ethereum, a contract is an account with storage that lives forever. On Bitcoin Cash, a contract is an address that holds coins and nothing else. There is no stored state to corrupt, no self-destruct, no delegatecall, and no reentrancy, because there is nothing to re-enter. A transaction either satisfies the contract's conditions or it does not, and every node checks that in isolation. There is also no gas. You pay a fee based on the size of the transaction, not on a computation budget that can spike while you are waiting. A contract that costs a fraction of a cent to use is arithmetic. WHAT CHANGED THIS YEAR Bitcoin Cash activated four upgrades in May 2026 under the name Layla, and they matter directly to anyone writing CashScript. Bounded loops arrived. Before, if a contract needed to check five outputs, you wrote the same verification logic five times. Now you write it once and loop. Functions arrived as well, so shared validation lives in one place. Bitwise operations came back, which lets a contract pack several permissions into a single token commitment and check one bit instead of comparing whole values. And Pay to Script made contract outputs a standard type, instead of a wrapper the rest of the network had to work around. The tooling followed. The compiler learned loops, the new bitwise operators and Pay to Script first. Then came reusable functions with multiple return values, imports so contracts can share code across files, global constants, and stack traces when a function fails. The practical difference is not cosmetic. One team rebuilding a prediction market contract collapsed pages of duplicated verification into a loop with a variable offset. More importantly, batch operations became possible: multiple buyers in one transaction, where before the contract hardcoded one. WHAT IS ALREADY BUILT This is not a proposal. Contracts written in CashScript are holding real money today. @BCH_BULL is the clearest example. It is a consumer app for leveraged long, short and hedge positions on BCH against dollars, gold, BTC and other assets, at up to 7.77x leverage, with no custodian. Every position is its own smart contract, generated on demand, and those contracts come from AnyHedge, which is written in CashScript. @ParyonUSD , the collateralised stablecoin, runs on 26 separate CashScript contracts. They are open source under an MIT licence, published to npm as a package other developers can import, and they have been through two external audits, the first delivered in three passes. Borrowing, redemption, liquidation and a stability pool are all enforced by script on the base layer. The same pattern shows up across the ecosystem. FundTokens runs on 20 CashScript contracts. Paytaca use it for escrow in peer to peer trades, where two strangers need a rule instead of a middleman. Tapswap uses it for non-custodial token sale offers. Bitcats Heroes, Cash-Ninjas and BCH PUMP all ship contracts written in it, for NFTs and token launches. One honest note on the ceiling. Cauldron, the main DEX on BCH, is written in raw Script rather than CashScript, and its constant product contract is a stack of opcodes that most developers would not want to hand-write. That route stays open for teams that need it. CashScript is the layer above, and its own documentation ships a version of that same DEX contract rewritten in the high-level language. WHY THIS MATTERS MORE THAN IT SOUNDS Every other ecosystem solves programmability by adding a layer. A rollup, a sidechain, a bridge, a sequencer. Each one is a new system with its own bugs, its own trust assumptions and its own operators. Bitcoin Cash solves it inside the transaction. A CashScript contract is just a locking script, and the coins in it are protected by the same proof-of-work as every other coin on the chain. There is no second system to audit, because the contract is the system. The code is short because the model removes entire categories of failure before you write a line. WHERE IT GOES NEXT The interesting shift is what developers can now build without leaving the base layer. Loops and functions turn a contract from a fixed decision tree into something that can iterate over a batch. Bitwise operations turn a token commitment into a compact permission record. Pay to Script shrinks the cost of the outputs those contracts create. Put together, that is the toolset for order books, vesting schedules, escrows with arbiters, recurring payments, and lending markets that settle atomically. Bitcoin Cash is programmable bitcoin. bitcoin-cash:native