Concepts

Smart Contracts

Canonical reference · Estimated read time: 10 minutes

TL;DR

Valdium contracts are plain JavaScript deployed as source code on-chain. They execute in a Hardened JavaScript (SES) Compartment — a frozen, capability-constrained sandbox. Contracts are immutable by default, async between each other (reentrancy is structurally impossible), and verifiable with a single hash compare.

The four pillars

Valdium's contract model rests on four properties that together eliminate the largest classes of on-chain bugs:

Pillar 1

Source deployed on-chain

Contract JavaScript source is stored on-chain verbatim at deploy time. Anyone can read it via eth_getCode. Verification requires one hash compare against the on-chain bytes — no third-party verification service, no trust in a bytecode decompiler.

Pillar 2

Immutable by default

Once deployed, a contract's source cannot be changed. There are no proxy patterns, no upgrade keys, no "owner can change everything" backdoors in the base model. If you want upgradability, you model it explicitly in your contract logic — and users can see that you've done so.

Pillar 3

Hardened JavaScript sandbox

Contract code runs inside a Hardened JavaScript (SES) Compartment. The global object is frozen. No access to the filesystem, network, timers, or any capability not explicitly granted by the host. The execution environment is deterministic across all platforms.

Pillar 4

Async message-passing — reentrancy impossible

Contracts communicate via async message-passing, not synchronous calls. A contract cannot call another contract and have that contract call back into it in the same execution turn. Reentrancy is structurally impossible — not prevented by a guard, removed from the model.

Source on-chain

When you deploy a contract, you send the full JavaScript source as the deployment payload. The chain stores it at the contract address and derives the contract address as BLAKE3(deployer_address || nonce)[0:20] — deterministic and pre-computable before deploy.

The contract's source hash is part of the deployment receipt. To verify a contract: fetch the source with eth_getCode, hash it with BLAKE3, compare to the deployment receipt. One step. No middlemen.

Hardened JS sandbox

Valdium uses SES (Secure ECMAScript) — the same hardening technology developed by the Agoric team for capability-secure JavaScript. When a contract runs:

The sandbox is evaluated to produce a contract object — a plain JavaScript object whose methods are the callable entry points. Calling a contract means calling one of those methods with the allowed arguments.

Async message-passing

Contract-to-contract calls use async message-passing. When contract A calls contract B, A does not block and wait — A sends a message and continues. B's handler runs in a subsequent turn. This is the key property that makes reentrancy impossible: by the time B runs, A's current turn is already complete.

Practically, this means contract code uses await when calling other contracts:

const result = await contracts.token.transfer(to, amount);

The await signals to the runtime that this is a cross-contract message, not a synchronous call. The runtime enforces the async boundary; there is no way to make it synchronous.

Gas and metering

Contract execution is metered in gas units. Gas is consumed by CPU-bound operations (function calls, storage reads/writes, arithmetic) and by memory allocation. The gas limit per transaction is set by the sender; if execution exhausts the gas limit, the transaction reverts.

Gas pricing follows Valdium's fee market — a base fee that adjusts per block plus a priority tip. See Fee Market for the full model.

Where to go next