.X3

The language

X3 is more than one payment.

X3 Shield on NEAR uses a narrow, tested slice of X3. Here's the whole pipeline, what the compiler refuses, the chain engine behind it, and what we're building next.

Enter Bootcamp — the in-depth .x3 developer course →

Two pipelines, one language

The hackathon path is the top line. The bottom line is the X3 chain, which is not part of the NEAR judge path.

NEAR Intents path · runs in the judge steps
  1. 01

    .x3 source

    Mandate and payment

  2. 02

    Compile

    Parse, type-check, lower

  3. 03

    Guard terms

    Hash-pinned on NEAR

  4. 04

    1Click quote

    Signature, then terms

X3 chain path · separate repository
  1. 01

    .x3 source

    Strategies and programs

  2. 02

    Rust compiler

    HIR, MIR, backend

  3. 03

    X3BC

    One canonical bytecode

  4. 04

    X3VM

    Atomic, signed receipts

What the compiler refuses

These programs never reach a quote. Each code is a real refusal in the checker that the playground runs.

X3_NEAR_ROUTE_SHAPE

More than one leg, or a fallback. 1Click settles one swap, and a second leg could half-execute with no rollback.

X3_NEAR_SLIPPAGE_REQUIRED

No slippage bound. The compiler will not choose a tolerance on the agent's behalf.

X3_NEAR_TIMEOUT_REQUIRED

No timeout. The deadline is when 1Click starts refunding, so it has to be stated.

X3_NEAR_NONCE

A payment under a mandate with no one-use nonce, or with two. Guard records each payment under its nonce.

X3_NEAR_REFUND_ASSET

A refund in a different asset or on a different chain than the deposit. 1Click refunds the deposited asset only.

X3_NEAR_REFUND_TO

Timeout and on_fail refund to different addresses, or to an address that is not on the origin chain.

X3_NEAR_GUARD_UNENFORCEABLE

A require clause the NEAR path has no way to enforce. It is refused, never silently dropped.

X3_NEAR_ON_FAIL_UNSUPPORTED

on_fail halt or quarantine. 1Click can only refund, so the program would promise something that cannot happen.

X3_NEAR_ROUTE_ENDPOINTS

The leg's assets don't match the intent's from and to.

X3_MANDATE_APPROVAL

An agent listed as its own approver, an approval threshold above the cap, or an impossible threshold.

X3_MANDATE_BOUND

A mandate that leaves slippage or fees unbounded.

X3_MANDATE_LIMIT

A per-payment cap above the daily cap, or a cap that does not fit the contract's u128.

Trigger them in the playground

The chain engine

Work in the X3 chain monorepo on unifying X3 Lang with the production X3BC bytecode and VM.

Repository not publicDraft PR, not merged to masterRuntime tests, not a live chainStatus as of 2026-10-19

One instruction set

A no_std core crate is now the only definition of X3BC opcodes, the bytecode format, the gas table, swap math, receipts and traps. Before, the compiler and the VM each kept their own tables, and those tables disagreed.

Trades that roll back as one

Trading opcodes run inside an atomic window that journals every write. If any step fails, the whole window reverts. Each run produces an Ed25519-signed receipt, and a replay recomputes the economics independently.

Compiled .x3 trades on the chain runtime

A kernel call executes compiled trading bytecode against the chain's own DEX, flash-loan and oracle pallets, with metered weight and refunds. Trading stays switched off until governance sets fees.

A language you can program in

Arrays, tuples, structs, indexing and len() compile from source through HIR and MIR to bytecode. Block-context opcodes (sender, height, timestamp, value, chain id) fail closed when the host supplies no value.

Robustness

A property-test harness ran 8 million cases with zero panics. Parser recursion is capped at depth 64, and there is a never-panics fuzz harness.

Bitcoin SPV, done properly

An SPV verifier that accepted a forged all-zero header was replaced. The new crate implements Bitcoin's real consensus rules and is checked against real mainnet blocks and Bitcoin Core's retarget test vectors.

You can't check any of this from here: the repository is private, so nothing on this page links to it. It is listed so the language's scope is clear. None of it is part of the NEAR submission, and none of it is cited as evidence on Inspect the Proof.

What we're building next

Guard enforces the program hash

Next

Main Guard stores an agent program's SHA-256 but does not check it. The Tidepool Guard already refuses an authorization whose program hash doesn't match the one the owner registered. Doing the same in agent_accept_quote would mean an approved mandate only carries the exact program the owner saw.

Scoped agent vault

Local prototypes

NEAR FunctionCall-only and Base EIP-712 vault work has local Sandbox and Foundry coverage in the source repository. Public vault deployment and independent audits remain unproven; these prototypes did not custody the historical Tidepool transfer.

Mandate diff before you sign

Idea

Compile the current and proposed mandate, then show the owner every term that changed (cap, recipients, refund address, expiry) before the create_mandate call goes out. The playground's checker can already produce both term sets.

One checker, three runtimes

Idea

Lower check_mandate to X3BC so the same bytecode runs in the browser, on the X3 chain and in the Guard. That removes the hand-kept ports and gives one parity test where there are three today.

Public refusal feed

Idea

An append-only feed of every agent proposal, with its .x3 hash, the verdict, the rule that decided it, and the transaction when there is one. Hostile-model runs would be labeled as attacks.

LP mandates

Idea

The same mandate shape, applied to liquidity: which pools an LP agent may enter, how much, the maximum price impact, and a fixed withdrawal address. Liquidity managed by an agent, bounded by the owner.

Want one of these sooner, or have a better one? Open an issue or back the work.