ConceptsCanonical reference · Estimated read time: 14 minutes

The Smart Contract Model

TL;DR

Smart contracts on Valdium are plain JavaScript running in a deterministic sandbox, immutable by default, verifiable from source, communicating via async message-passing, and economically rewarded for being small and modular. Together these four design choices create a contract experience that is meaningfully safer than Ethereum's while also being friendlier to JavaScript developers.

What's broken on Ethereum

Smart contract platforms have spent a decade learning hard lessons, mostly by losing billions of dollars to exploits. The four most expensive classes of problem:

1. Reentrancy. The DAO hack in 2016 (~$60M) and a long tail of exploits since. Caused by the synchronous-call model allowing a contract to be re-invoked mid-execution.
2. Upgradeable contracts with hidden upgrade keys. Users think they're interacting with audited code, but a multisig the developer controls can swap in new code at any time.
3. Unverified bytecode. Bytecode on-chain, source code elsewhere. Users have to trust a third party that the source matches the bytecode.
4. Complex monolithic contracts. Big contracts are hard to audit. Ethereum's gas model incentivizes monoliths over modular designs.

Valdium is designed to remove all four structurally — not just mitigate them with patterns and discipline.

The four pillars

1. Async message-passing between contracts

Contract A cannot synchronously invoke contract B and wait for a return value mid-execution. Instead, A sends a message to B and receives a promise:

async function transfer(tokenRef, to, amount) {
  const result = await E(tokenRef).transfer(to, amount);
  if (!result) throw new Error('transfer failed');
}

Reentrancy is structurally impossible. When a contract sends a message to another contract, it can't be interrupted and re-entered mid-execution. The DAO hack cannot happen here. Within a single contract, code is normal synchronous JavaScript.

2. Immutable by default

A deployed contract's code is locked in at deploy time and cannot be changed, ever, unless the author explicitly built in a proxy pattern. When they do, the proxy is visibly labeled as such in explorers and wallet interfaces. When you audit a contract, you know what you're getting.

3. Verifiable by default

Contracts are deployed as plain JavaScript source, not compiled bytecode. Verification is a single hash comparison:

hash(submitted_source) == deployed_code_hash

There is no compiler to trust, no "Etherscan verified" third-party dependency. The source on-chain is the source. Block explorers show contract source directly, with syntax highlighting.

4. Economic rewards for small, modular contracts

Valdium's contract pricing has three layers that create economic pressure toward small, composable, single-purpose contracts: deployment fee scales with source size, cold-load surcharge on first call per block (proportional to code size), and per-op gas for actual execution.

For developers

What stays the same: you write JavaScript. Normal modern JS — async/await, classes, closures, BigInt, Map, Set. TypeScript types can be stripped at deploy time. Your editor and tools still work.

What's different (in good ways):

Cross-contract calls are async: await E(otherContract).method(...)
No reentrancy guards needed — the language doesn't permit it
Contracts are immutable by default — use proxy pattern explicitly for upgradeability
Source is public — every deployed contract is readable in the explorer as source, not bytecode

Recommended patterns

One contract per concern. Tokens, oracles, accounting, access control — each in its own small contract.
Capability passing. Pass contract references between contracts explicitly rather than using a global registry. Makes security model visible and auditable.
Transaction bundles for atomicity. When a user needs "borrow → swap → repay" to succeed or fail as a unit, use the protocol's transaction bundle type.