Blockchains are widely appreciated for their decentralized, permissionless nature and programmability. Smart contracts are among the most important features, but not all major blockchains currently support them. In a webinar with EvolvH3R, the Nexa team developer, David Thibodeau, walked through smart contracting on Nexa and explained how it operates under the UTXO model, drastically improving the protocol’s usefulness and usability.
Find a full video webinar below with a transcribed article, and the original presentation attached at the bottom.
Introduction
David is a developer with Nexa. He has worked with the project on and off for a few years and joined full time at the end of 2025, focusing mostly on the application side, where he has done a lot of smart contracting.
His presentation keeps the material approachable for newcomers while giving enough background on the underlying technology to understand how smart contracts work on Nexa.
What is Special About Nexa
Nexa is a fair launch Layer-1 blockchain. It uses a UTXO proof-of-work model, just like Bitcoin. The native coin is called NEXA, and denominations are in satoshis, where 100 satoshis equals one NEXA. Native issuance for group tokens is built right into the protocol, and that covers both fungible tokens and NFTs.
A couple of things set Nexa apart. It has very high transaction throughput. The network has been load tested at over 60,000 transactions per second to date, and it has very low fees, a tiny fraction of a cent per transaction. The Nexa team has also implemented script based smart-contracts with introspection capabilities, which is a key piece of technology currently missing from Bitcoin.
The brief history is that this all started from Bitcoin. The network hard forked into Bitcoin Cash, and the Bitcoin Cash code base was then forked again. The Nexa team significantly enhanced it, and that is what ultimately led to Nexa.
Foundation: The concept of a UTXO
A UTXO is a coin. It has an amount and locking script, also known as a constraint script. To spend that coin, the spender provides a satisfier script that makes the combined script evaluate to true.
Once a UTXO is spent, it is consumed and new UTXOs are created. So if a UTXO worth 20 is the input to a transaction, it can split into two outputs, say one of amount 10 going back to the sender and one of amount 10 going to somebody else. The original locked UTXO has been destroyed, and two brand new UTXOs of amount 10 have been created.
David offers a real world analogy. Imagine handing a $20 bill to a merchant, and that bill is permanently destroyed the moment it changes hands. Two new $10 bills are printed kind of out of thin air. The merchant keeps one, and the buyer receives the other as change. That is the real world concept of a UTXO.
There is No Line Between Sending Coins and Running a Contract
Here is the important part. On Nexa, there is no real difference between sending coins and executing a smart contract. They are both the same thing: proving the right to spend a UTXO by satisfying its constraint script. A regular transaction is just providing a valid signature for the owner’s public key. A contract is a more complex constraint, where the spender might be providing an oracle signature to prove a price condition was met, or ensuring the outputs go to the correct people. Whatever conditions the contract was created to enforce, the script enforces. Once they are met, the coin can be spent.
So contracts are not a separate system layered on top of the blockchain. They are a natural extension of the same spending mechanism almost every transaction already uses.
Stack-based Script Evaluation
Scripts on Nexa execute on a stack machine, again very similar to Bitcoin and Bitcoin Cash. Data is pushed onto a stack and operations are executed. There are no real loops, which means there is a bounded execution window. Scripts always have a termination point and a finite number of instructions.
David walks through a simplified, toy example. The satisfier script runs first and pushes its data onto the stack, say a 4 and then a 3. Then the constraint script runs. The first opcode is OP_ADD, which takes the 3 and the 4 and adds them to get 7. The constraint script then pushes its own 7 onto the stack, and finally OP_EQUAL compares the two values for equality. They match, all three items disappear, and the stack is now clean. A clean stack is the condition for a valid spend.
In a real transaction the spender would be signing the transaction and that signature would be checked, but the mechanism is the same. And all of this is fully validated via network wide consensus, meaning every node running the script machine will agree on whether a script executes or not.
The Key Opcodes
The most important opcode is OP_PARSE. This is the one Bitcoin and Bitcoin Cash never got around to implementing, and it is essentially what makes smart contracts work on Nexa. OP_PARSE knows where each piece of data sits inside the hex of a transaction. It operates like a template and accesses the data contained in individual fields. Some of that data is hashed together and some of it is unhashed, but it lets a script inspect the entire transaction structure, the inputs, the outputs, and the destination addresses, so it can see exactly which wallets are being paid.
The other key opcodes: OP_VERIFY asserts that a condition is true, and if it is not, the script fails. OP_CHECKLOCKTIMEVERIFY is for contracts that want to enforce time based conditions. OP_CHECKSIGVERIFY and OP_CHECKDATASIGVERIFY are the signature verifications, making sure a valid Schnorr signature was applied against a specific public key. And then there is a set of standard arithmetic and comparison opcodes: add, subtract, divide, greater than, less than, and so on.
Decentralized Oracles
An oracle is a trusted provider that signs statements about real world events. An oracle can be created to sign any piece of data imaginable. Nexa uses a couple. One signs the price of NEXA at given timestamps, hourly and daily averages. Another signs the scores and outcomes of sporting events.
A contract takes the oracle’s signature, compares it against the oracle’s well known public key, and verifies that the spending proof was signed by the correct oracle. That public key is hard coded into the contract at compile time. The oracle itself does not know or care about any of the contracts. It does not know the participants and it does not know who bet on what side. If it is settling a bet, the only thing the oracle knows is the score or the outcome of the event. It simply publishes signed facts.
The price oracle is publicly viewable on Wally Wallet website. Calling it returns a structured response: a type, such as hourly average, and a message containing some hex data and a hex Schnorr signature. The data committed to in that signature is three fields, a timestamp, a price, and the ticker pair USDT/NEXA. The values are parsed out of a well known structure, a fixed number of bytes per field, and the signature checks out.
Nexa Smart Contracts versus Ethereum
For those who have worked with smart contracts before, EVM style contracts will be familiar, and Nexa is quite a bit different.
Nexa is UTXO based, Ethereum is account based. A Nexa contract is spent once and executed once. An Ethereum contract is deployed, lives at an address, and keeps an internal state, with many transactions interacting with it over a long period of time. On Nexa there are well known contract templates. A specific instance of a contract can be deployed many times on-chain, but each time it is spent, the entire UTXO is consumed. Contracts are one and done on Nexa. Reusing a contract for another transaction simply means deploying a whole new transaction with that contract’s bytecode attached.
Nexa uses stack based script evaluation every time a UTXO is spent. Ethereum uses a Turing complete virtual machine that maintains state and storage. Nexa is stateless, Ethereum is stateful. Inputs are validated independently on Nexa. In a single block there could be ten instances of the same contract, the same type of bet, launched for ten different participants, and all of them can be evaluated independently within that block. On Ethereum, execution is sequential, because each transaction is manipulating the state inside the contract, so there has to be an order.
Nexa does not have gas, or any fee that depends on how much execution the script machine performs. On Ethereum, the more computation a contract requires, the higher the fees. On Nexa, a contract costs a fraction of a penny no matter how complex it is.
David frames the difference as a mental model. With Ethereum it is, “calling a function on a deployed program that changes its internal state.” With Nexa it is, “proving that a specific transaction satisfies a specific set of conditions that were encoded and embedded into a UTXO when those coins were locked.” Both are fully programmable, both enforce rules, both rely on cryptographic verification, and both are capable of oracle integration.
The Problems Solved By UTXO-based Architecture
Because the architecture is completely different, Nexa avoids several well known classes of Ethereum problems. The DAO hack and the Curve Finance exploit are well known examples worth researching for context.
Reentrancy attacks. On Ethereum, one contract calls another mid-execution, something gets corrupted before control returns, and the contracts are left in a broken state. Nexa scripts do not call other contracts. A single spend consumes the contract’s UTXO and it no longer exists, so there is no reentrant path to exploit.
State mutation bugs. Ethereum contracts constantly modify persistent storage, updating balances, mappings, and flags. A bug in one of those state transitions can permanently break a contract, and the funds locked in it become stuck, often unrecoverable. This happens more than one would think. Nexa contracts are stateless. The UTXO exists or it has been spent. There is no mutable state to corrupt.
Gas attacks and out of gas reverts. On Ethereum, a caller has to estimate how much gas a call will take and attach enough to cover it. Miscalculate and the contract can eat the gas and revert before finishing, cancelling the transaction. There are also gas griefing attacks. None of this exists on Nexa. It is a very small, fixed transaction fee, with no guessing.
Front running and MEV. On Ethereum, miners can reorder contract calls, and even insert their own, to profit from how a buy or sell lands. On Nexa, a UTXO is spent from once and then it no longer exists, so there is no reordering. The call happens once and is consumed.
Explicit value transfer. On Ethereum, token transfers happen behind a complex pile of code, and the internal state changes are not really visible. On Nexa, every transaction is bytecode that translates into opcodes. The script verifies the mapping between inputs and outputs directly. What you see is what you get.
Audit complexity. Auditing an Ethereum contract can mean crawling through hundreds or thousands of lines, and a lot of the time it comes down to taking it on faith that the developer wrote it correctly. A compiled Nexa contract boils down to a script of opcodes. With a tool like debug.nexa.org, an auditor can paste a script in and step through the entire execution, watching which values are on the stack and how each opcode behaves, just like the stack walkthrough above.
Contract Argument Types
Before the contract example, there are a few argument types to understand.
Template args are baked into the contract bytecode at compile time. They are fixed at creation and they change the template hash, which is the unique identifier for a contract on Nexa. Change a template arg and the contract appears as something entirely new on-chain.
Holder args are passed in differently and do not change the contract hash. They are attached as part of the contract script after compile time, and they are hashed together into one blob, so they cannot be seen.
Holder public args, also called visible args, are the same idea except each one sits in its own field of the template script. They are nice and neat and separated, and anybody on the blockchain can view them.
Spender args are the arguments supplied at spend time, the conditions that must be provided for the contract to evaluate, such as an oracle signature or a signature from a trusted party.
A Worked Example: The Fixed Time Prediction Contract
This contract has two participants betting on the future exchange rate of NEXA/USDT at a specific future timestamp. Call the two participants Alice and Bob. Alice bets the price will be greater than a threshold, Bob bets it will be less than that threshold.
Up top, the contract declares the data it expects: timeout deadlines, which set how long before the offer can time out and refund; the tickers, which here are hard coded to NEXA versus USDT; a holder hash for Alice and one for Bob, which are the wallet addresses they want to be paid at; a deployer args hash for the platform deploying the contract and taking a small fee; a settlement timestamp; and the amounts Alice and Bob are each betting. At spend time, it expects an oracle signature and a signed oracle message.
The rules work like this. For “Alice wins,” the contract checks the oracle signature against the oracle data, parses out the ticker, timestamp, and price, and verifies them against the hard coded timestamp and target price the contract was created with. It then confirms the oracle signed a price greater than the target. The “Bob wins” rule is the same, except it verifies the price did not reach the target and that the winner hash is Bob. Either way, the contract calculates the payouts, pays the platform its fee, and uses OP_PARSE to guarantee the money is routed only to the correct destinations, one for the deployer and one for the winner.
There is also an exit rule. Suppose the oracle never signs an outcome. After a configurable lock time passes, anybody can invoke this rule, which verifies the amounts and destinations and refunds Alice and Bob their money, minus a small facilitation claim.
That facilitation claim points to something powerful. Because the holder public args are visible, any miner can see this is a bet, identify it by its template hash, watch the oracle, and construct the transaction to settle it on behalf of the participants. The catch is they can only spend it to the correct parties. If a participant wins, any miner can unlock the coins, but the only thing they can do is send them to that winner. The incentive is a small fee the contract deliberately leaves on the table for whoever advances it. That creates a brand new role in the ecosystem, the on-chain facilitator.
Delegation Contracts
The contract above needs two participants to organize the transaction at the same time, or a third party app that knows how to build it. A delegation contract is the setup for that, and it is a one person contract.
A participant locks funds into a delegation to make an open offer to anybody on-chain. Using holder public args that everyone can see, plus OP_PARSE introspection, the delegation commits to the hash of the specific contract the participant is willing to engage in and allows the funds to be spent only into that type of contract, and only if the counterparty meets the stated terms.
For example, someone could offer to bet on the future price of Bitcoin versus the US dollar token, locking in 50,000 NEXA on an unlikely price and requiring the opponent to wager double, 100,000 NEXA. The delegation guarantees the money can only be spent into a contract for that same pair, that same timestamp, and those same wager amounts. It is an on chain offer to engage any willing participant who can meet those specific terms. As David repeated, Bitcoin and Bitcoin Cash do not have OP_PARSE, which is exactly why they cannot do this.
Participants and Ecosystem Roles
Alice and Bob are the end users making predictions, whether on sporting events or price outcomes. The same mechanisms also drive blockchain gaming.
The deployer is the application or service that constructs the contract transactions.
The facilitator is any on-chain entity or miner who advances a transaction to a settled state without the participant needing to be online.
The oracle is the third party data provider whose signed proof unlocks the ability to spend from a contract.
The super facilitator is one trusted public key a service can hard code into a contract before compile time. Say someone makes an open delegation offer, the odds move, and they no longer want it. The funds are locked, so the only way to cancel and get a refund, assuming nobody has taken the offer first, is the super facilitator rule, which lets that one delegated entity send the coins back. Some contracts use it, some do not.
Why This Matters to the Nexa Ecosystem
The goal is to compete, and to have users decide they prefer the security and safety of Nexa smart contracts. The Nexa team hopes to attract people from chains like Solana and Ethereum who realize Nexa contracts are just as capable, and in a lot of cases safer to interact with.
There is also a very low barrier to entry. Trying to make a one or two dollar bet on Ethereum using smart contracts is not going to happen, the gas fees eat it all. On Nexa, even a one or two cent bet is worthwhile, because the fees are that small.
The example contracts are simplified, just a bet between two participants, but they show the full capability to ensure specific parties get paid specific amounts, and to let either everybody or only specific parties settle and spend the coins. There is a lot of complex mechanism inside those simple contracts, and it shows Nexa is perfectly capable of supporting any kind of decentralized financial application.
Finally, facilitators create real value for miners. Permissionless settlement means anybody can claim on behalf of the winner, the winner does not have to be online, and the payout is always guaranteed. That is a new revenue stream beyond block rewards and regular fees. Nexa just had its first halving, and it is on the same schedule as Bitcoin, so over time those mining fees shrink. Miners are the source of security for any blockchain network, so giving them additional revenue matters.
Current Uses
Two applications already run on Nexa’s test network, and both require the Wally Wallet to use fully.
Nexa Warriors is a battle card game, similar in spirit to Magic or Pokemon, but using NFT group tokens instead of physical cards. Smart contracts lock a number of each player’s cards before a battle, and the outcome determines whether a player gets all of their cards back or forfeits some to the winner.
NexPredict is prediction and peer to peer betting using only smart contracts. Normally a bettor would send a sportsbook their money and trust it to pay out on a win. Instead, the service constructs a transaction the user’s wallet approves, and once approved, the funds are secured inside a smart contract on chain. No third party holds the money. If an oracle proof exists confirming the outcome, the coins are returned to the user, or any on-chain facilitator can do it for them.
Future Directions
Looking ahead, there are nearly unlimited directions, both for DeFi and blockchain gaming. A few are under development. Delegation circular spends, where someone could offer a one million NEXA bet to the whole chain, another participant accepts 400,000 of it, and the remaining 600,000 flows right back into the delegation contract so it stays available for others. The Nexa team is also working on delegation bound multi party contracts, so instead of a two person contract there could be a hundred or a thousand person contract. And it intends to keep pushing OP_PARSE to do more with group tokens, including using them for prediction markets rather than just peer to peer betting, and for tradable tokens in other financial applications.
A Note on Auditing
A common question is whether auditing a Nexa contract means learning Nexa’s programming languages. It does not. The source code a contract is written in is Nexa’s Kotlin domain specific language, but when it compiles down and goes on-chain, it is just those opcodes. Anyone who understands what the opcodes do, or who uses debug.nexa.org to paste a script in and step through it, can evaluate a contract fully with far less knowledge than it takes to read Solidity and audit an Ethereum contract. There is no need to learn a specific programming language to audit on Nexa. It mostly comes down to learning to use the debugger and checking whether a script will execute.
It is a much smaller audit surface than most Ethereum contracts, and it is more transparent, with far less content to go through. The entire script machine runs on a very small set of opcodes, similar to Bitcoin with a few added, whereas Solidity defines thousands of functions, and unless an auditor knows the whole language they cannot really be sure what an EVM contract is doing.
On whether more opcodes mean more vulnerabilities, David’s view is that each opcode is something simple, like adding two stack items, multiplying them, or swapping items around on the stack. If a new opcode is implemented incorrectly, that could be a bug in the implementation, and under certain conditions it might do something unexpected. He describes that as less of an attack surface and more of a bug surface. The benefit of adding opcodes is more functionality, and it is what enables smart contracts on Nexa in the first place. Bitcoin and Bitcoin Cash could have these capabilities by adding a couple of simple opcodes. They just have not implemented them.
Learn More
A full smart contracting library for developers is coming soon. In the meantime, the code lives on Nexa’s GitLab repository, which holds libraries and projects for anyone who wants to build on Nexa. The Discord and Telegram channels are open, with community moderators, managers, and developers active every day. The main resources are nexa.org and the technical documentation at spec.nexa.org.
Nexa Telegram: https://t.me/nexacoin
Nexa Discord: Nexa
Download the presentation:
https://nexa.org/documents/an_introduction_to_smart_contracts.pdf
