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

The first proposals from outside the core team have landed in BCH-1. It's time to explain how they work. Most funding pipelines blur two things together: the decision to approve work, and the decision to pay for it. This one is built to keep them apart at every step. WHAT A PROPOSAL HAS TO SAY It is not an invoice with a pitch attached. It is a case for a change: the problem worth solving, the benefit to Bitcoin Cash, and what still needs to be understood before anyone builds anything. Five sections carry it. A title and a short abstract. The rationale, evidence and scope, with delivery kept apart from hoped-for results. The open questions, and what research would need to answer. A delivery plan and an optional budget. And up to ten supporting files, each labelled with what it establishes. 01 SUBMITTED A submission starts private. It goes public when BCH-1 publishes it or moves it into research. Being visible is not approval, and it does not set aside any money. 02 ALIGNMENT REVIEW One question: should this go into research now? BCH-1 checks whether the work fits its goals and supports public goods for Bitcoin Cash. The answer can be yes, revise, or not now. A yes funds the research phase and nothing beyond it. 03 RESEARCH Research turns the idea into a plan someone can be held to. A workgroup tests feasibility, obstacles and costs, and names who drives the work and who signs off the delivery. It sets payment conditions, milestones or bounties, completion criteria and target dates. Every item cost has to add up to the researched budget. Saving the findings does not close the review; that happens once the plan is agreed. 04 REVIEW COMPLETE Now there is a decision on the record: approved, insufficient funds, delayed or rejected. The reason sits next to the votes and any recusals. In Phase 1 the public lead makes that call alone. Approval still does not move money. 05 IN PROGRESS Work runs against the completion criteria. Monthly updates, evidence for each item, then an acceptance review. Payouts happen during this stage, released against the milestones or bounties set in research, and each payout is recorded apart from the acceptance. Work that stalls stays on the page, so nobody has to guess whether it is late. 06 COMPLETE Every item accepted and a final report published before the proposal can close. The report sets results next to the plan, so a reader can compare what was promised with what was delivered. Completion is a statement about the work, and the report is where that statement is made. WHICH FUND The Core Fund is for work that benefits the wider ecosystem. A large project with a large individual ask outside public goods goes to FundMe, where a campaign sets its own scope and terms. FundMe is not a dropdown in the proposal form. That is also the honest contrast. A FundMe campaign runs one pitch for the whole sum, so deciding to back it and paying for it are the same act. The Core Fund pays against conditions written down in research, and records acceptance and payout separately. WHAT THE SEPARATION IS FOR Publication is not approval. Alignment is not funding. Approval is not payment. Acceptance is not payout. Completion is not settlement. Five decisions, five records. A proposal that looks funded and one that delivered look the same from a distance, and this pipeline is built so you can tell them apart without taking anyone's word for it.