But the way most blockchain networks run smart contracts has a structural problem. The industry has spent years and billions of dollars finding this out.
Every node runs the same code
In most blockchain systems, Ethereum, being the clearest example, smart contracts run directly on the network. When a transaction triggers a contract, every node executes the same code, updates the same shared state, and reaches the same result. That's what makes it trustless: no single party controls execution.
The consequence is that the entire network becomes a shared computer, and every user competes for space on it. Contract execution requires gas, a metered unit of computation, and when demand rises, gas prices spike. An interaction that costs a few dollars at quiet times can cost hundreds at peak. The pricing is unpredictable, and that unpredictability is built into the design.
Every node runs the same contract code. Every user pays for that shared execution and competes with every other user for access to it.
The gas model also means that complexity costs money in a very direct way. Developers spend significant time optimising for gas efficiency, a constraint that shapes not just how things are built, but what gets built at all.
The attack that won't go away
There's a deeper problem, and it's harder to engineer around. When contract logic runs on-chain in a shared environment where contracts can call other contracts, it creates an attack surface that has proven stubbornly difficult to close. Reentrancy attacks — where a malicious contract drains funds by exploiting the execution order of an external call before state is updated — have caused over $350 million in documented losses by 2023, with incidents increasing in frequency.
The original example is still the clearest. In 2016, a reentrancy attack on The DAO drained 3.6 million ETH, worth around $60 million at the time, and was serious enough to split Ethereum into two separate chains. Ten years later, the same class of vulnerability is still being exploited, in projects that had been audited and were considered safe.
This is a structural consequence of running arbitrary code in a shared, composable environment. An attacker who controls one contract can manipulate execution order across others. The attack surface is large and difficult to reason about completely, regardless of how careful the developers are.
Move the logic, keep the security
eCurrency takes a different approach. Contract logic runs on the client side, in applications and systems that interact with the blockchain. The blockchain's job is to verify that a transaction is valid: signatures are correct, assets are unspent, and protocol rules are satisfied. That verification is bounded and deterministic. It doesn't involve running a program of unknown complexity.
The blockchain verifies outcomes. The logic that produced those outcomes runs elsewhere. Security is enforced at the settlement.
In practice: the parties to a transaction define and execute their contract logic — payment conditions, distribution rules, conditional transfers — in their own applications. When the conditions are satisfied, a standard transaction is submitted. The network checks whether it meets the protocol rules and settles it. It never runs the logic that produced the transaction.
What disappears
When the network doesn't run arbitrary code, entire categories of vulnerability no longer apply. There's no reentrancy attack surface because there's no shared re-entrant execution environment. There's no gas griefing because there's no gas model. There's no infinite loop denial-of-service because the network doesn't run loops. There's no storage manipulation because the contract state doesn't live on-chain.
The security question changes from 'is the execution environment safe enough' to 'does this transaction satisfy the validation rules.' The second question is significantly more tractable.
What stays
Moving execution off-chain doesn't mean giving up programmability. Conditional payments, time-locked transfers, multi-party settlements, revenue distribution, automated payment schedules — all of this is expressible through transaction structure: spending conditions, script logic, multi-signature requirements, hash commitments.
Developers building payment applications on eCurrency don't need to think about gas optimisation, reentrancy guards, or shared execution semantics. The logic lives in the application layer, where software developers are already working. The blockchain layer handles what it's actually good at: reliable, verifiable settlement.
Why this matters for payments specifically
The global execution model made sense as a general-purpose design choice. Building a decentralised application that handles arbitrary financial logic, governance, or complex token mechanics requires a Turing-complete environment that every node agrees on.
Payment infrastructure has different requirements. Payments are value transfers with conditions. The conditions can be sophisticated, but the core operation is transfer. Building payment infrastructure on a global virtual machine means inheriting all the complexity and risk of that model for an application that doesn't need most of it.
A global computer is the right tool for some problems. Payments aren't one of them.
eCurrency is designed for payments. The client-side smart contract architecture is a direct consequence of that. Complexity belongs in the application layer. The base layer stays lean, verifiable, and predictable. That's exactly what settlement infrastructure needs to be.
