The chain that governs its own programming language

Most blockchains have a hardcoded instruction set. If you want to add a new opcode to the EVM, you write an EIP, coordinate across a dozen client teams, schedule a hard fork, pray nobody ships a bug, and wait months. It's governance by social consensus — humans talking to humans, hoping everyone upgrades.

Asentum does it differently.

what we built

A governance contract at 0x0000000000000000000000000000000000000003. Anyone can propose. Token holders vote by sending ASE (vote weight = tokens locked). When a proposal passes, its effects take hold automatically across every validator node on every continent. No restart. No config file. No human who could refuse.

The first thing we governed: the programming language itself.

how it works

Smart contracts on Asentum run in a SES (Secure ECMAScript) sandbox with a fixed set of globals: storage, emit, assert, msg, chain. No imports, no require, no fetch. The sandbox is locked down.

But the globals aren't hardcoded anymore. They're read from on-chain state — specifically, from the governance contract's storage. When a library is approved via governance vote, its JavaScript source gets stored at lib:<name> in the governance contract. Every time a contract runs, the VM reads the approved-library list from the governance contract's storage, evaluates each library in a sandboxed sub-Compartment (no host APIs — pure functions only), freezes the result, and injects it as a global.

Since on-chain state is deterministic and identical across all nodes at every block height, the library injection is automatically enforced everywhere. Zero human intervention.

the proof

We proposed a math library on the live testnet:

propose("Add @std/math library",
  "Basic math utilities: PI, E, abs, floor, ceil, round, min, max, pow, sqrt, clamp.",
  "library",
  "20",       // voting period: 20 blocks (~40 seconds for testing)
  "math",     // global name in contracts
  mathSource  // full JavaScript source, stored on-chain
)

Voted FOR with 1,000 ASE. Waited 40 seconds. Executed. The governance contract stored the library source on-chain and emitted LibraryApproved.

Then we deployed a contract that uses the math global — a global that didn't exist 60 seconds earlier:

({
  getArea(r) { return String(math.PI * parseFloat(r) * parseFloat(r)); },
  getSqrt(n) { return String(math.sqrt(parseFloat(n))); },
  getPI()    { return String(math.PI); },
})

Called it:

getPI()      → 3.141592653589793  ✓
getArea(5)   → 78.53981633974483  ✓
getSqrt(144) → 12                 ✓

The math global was voted into existence by token holders and automatically appeared in every contract's execution environment across 4 validator nodes on 3 continents. No human deployed it. No human configured it. The governance vote IS the deployment.

the security model

Libraries run in their own sub-Compartment with no host APIs:

• No storage.get/set — can't read or write contract state
• No emit — can't create events
• No msg — can't read the caller
• No assert — can't revert

Pure functions only. A library can compute, transform, and return values — but it can't DO anything to the chain. The contract that calls the library's functions is the one with the host APIs. This means an approved library can never directly steal funds, corrupt state, or emit fake events.

The result of evaluating the library source is harden()ed (frozen via SES) before being injected as a global. Contracts can't mutate the library at runtime.

the chain-level rules

After the initial implementation, we hardened the governance contract with on-chain rules enforced by assert() — the VM reverts the transaction if any rule is violated. No exceptions. No admin override.

• Minimum voting period: 2,160 blocks (~72 minutes). No flash governance.
• Maximum voting period: 604,800 blocks (~14 days). Proposals can't run forever.
• Proposal bond: 100 ASE, sent with the proposal. Returned if quorum is met; forfeited if not. Anti-spam.
• Minimum quorum: 1,000 ASE total vote weight must participate. Without this, a single small holder could pass anything. If quorum isn't met, the proposal gets no_quorum status — not passed, not rejected.
• Execution delay: 100 blocks (~3.3 minutes) after voting ends before the proposal takes effect. Gives the community time to react.
• init() replay protection: the governance contract can only be initialized once. assert(!storage.get('initialized')).
• Library name validation: must be a valid JavaScript identifier (/^[a-zA-Z_][a-zA-Z0-9_]*$/). No @std/math as a global name — it's just math.

These rules live in the contract source at 0x0000...0003. Every validator node on every continent evaluates the same assertions on every transaction. There is no "but" in Asentum. There is only code and truth.

what this means

Asentum is the first blockchain where the programming language's capabilities are governed by the token holders. The VM is not static — it evolves at the pace the community chooses, through the same consensus mechanism that produces blocks.

A governance vote to "approve utils library" adds string helpers to every contract globally. A vote to "remove math library" takes it away. A vote to "add crypto library with SHA-256 and HMAC" gives every contract access to cryptographic primitives that weren't there yesterday. All deterministic. All automatic. All governed.

This is what decentralization looks like when you take it seriously.

— milkie