Skip to content
PaxLabs.
— Paxeer Network · Token Primitive

Tokens that think.

For years, tokens have done two thingshold value, or represent ownership. The Computable Token Machine introduces a third dimension: computation.

Digital tokens have served two functions since the first ERC-20 deployment. They store value. They represent ownership. They sit in wallets and they wait to be moved. Every token on every chain, for seven years, has been a passive asset on a register.

The Computable Token MachineCTMis a token standard in which every token is a complete, modular execution environment. Not a record. Not a receipt. A program.

A CTM can run a decentralised exchange inside itself. It can manage its own governance votes. It can orchestrate the behaviour of an autonomous on-chain agent. All from within a contract that also happens to be ERC-20 compatible at its boundary. The token and the logic are not separate systems talking to each otherthey are the same object.

Two personalities in one contract

A CTM is a smart contract that combines a standard token interface with the Diamond Standard (EIP-2535). The external surface is familiar: a wallet can hold it, an exchange can trade it, a protocol can compose against it. The internal surface is where the behaviour lives.

On the inside, the CTM is a proxy. Function calls are routed to Programssmall logic contracts (facets, in Diamond terminology) that define what the token can do. Programs can be added, replaced, or removed over time. The token's address never changes. Its balance ledger never moves.

The token is the container. The Programs are the software the container runs.

What this unlocks

  • Infinite extensibility. Add new features to a live token years after it deploys. The token evolves with its protocol.
  • Shared state. A staking Program can read directly from a governance Program. They are not two contractsthey are two modules inside the same contract.
  • Gas efficiency at scale. Modular Programs sidestep the EVM contract size limit and let you lazy-load only the logic a given call needs.
  • True on-chain autonomy. A CTM can hold assets, call other protocols, and execute conditional logic based on its own rich state. It is an on-chain agent with a balance sheet.

A first deployment

A CTM deployment is three contracts. The proxy itself (TokenVM.sol), the standard Diamond facets (cut / loupe / ownership), and a base ERC20Facet that gives the token its wallet-facing behaviour. The repository ships a Hardhat script that wires all of it in a single transaction. 

npm i @paxeer-foundation/ctm-contracts
git clone https://github.com/Paxeer-Network/Pax-v3-coreCTM.git
cd Pax-v3-coreCTM
npm install
npx hardhat run scripts/deploy.js --network <your-network>

The script returns the permanent address of the CTM. That address is the anchor. Every Program ever attached to this token will be called at this address. The token's identity is immutable; the token's behaviour is not.

Programsthe unit of behaviour

A Program is the atomic unit of CTM functionality. A Program is a standard Solidity contract with one unusual constraint: it is stateless. It does not declare its own storage. Instead, it reaches into a designated slot of the CTM's storagederived from a unique keccak256 hashand reads or writes its state there.

This is the critical discipline. Programs share a single storage context, which is what lets them compose freely. But because every Program anchors its state to a hashed namespace, they cannot collide with each other by accident. Discipline at the library level; freedom at the composition level.

Examplea voting Program

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {ERC20Facet} from "./ERC20Facet.sol";

contract VotingProgram {

    struct VotingStorage {
        mapping(uint256 => string) proposals;
        mapping(uint256 => mapping(address => uint256)) votes;
        uint256 proposalCount;
    }

    bytes32 constant VOTING_STORAGE_POSITION =
        keccak256("ctm.program.storage.voting");

    function votingStorage()
        internal
        pure
        returns (VotingStorage storage vs)
    {
        bytes32 position = VOTING_STORAGE_POSITION;
        assembly { vs.slot := position }
    }

    function createProposal(string calldata _description) external {
        VotingStorage storage vs = votingStorage();
        vs.proposalCount++;
        vs.proposals[vs.proposalCount] = _description;
    }

    function vote(uint256 _proposalId) external {
        uint256 voterBalance = ERC20Facet(address(this))
            .balanceOf(msg.sender);
        require(voterBalance > 0, "Voter must hold tokens");

        VotingStorage storage vs = votingStorage();
        vs.votes[_proposalId][msg.sender] = voterBalance;
    }
}

Notice the crucial line: ERC20Facet(address(this)).balanceOf(msg.sender). The Program is calling back into the CTM that hosts it, reading the voter's token balance, and using it as voting weight. This is not interoperability between two contractsthis is one contract talking to itself.

Attaching this Program to a live CTM is a single transaction: a call to diamondCut that registers the Program's functions against the proxy. From that moment forward, createProposal and vote are callable at the CTM's address as though they had always been there.

Security considerations

The power of the Diamond Standard is also its sharpest edge. Three disciplines keep CTM deployments safe:

Storage layout

Always anchor a Program's state inside a struct stored at a keccak256 hash. Never declare naked global state variables in a Program. A single collision between two Programs' storage will corrupt both.

Access control

diamondCut is the most consequential function on the CTM. It can add or replace any behaviour the token exposes. Guard it with the OwnershipFacet, a multisig, or a governance Program. Unprotected diamondCut is a token rug.

Stateless logic

Programs are logic, not state. Do not give them constructors that set storage. Do not hold funds in Program contracts themselves. All state lives inside the CTM proxy; Programs simply describe how to interpret that state.

What this means

The ERC-20 was the simplest possible substrate for digital value. That simplicity was its virtue for the first decade of on-chain finance. The CTM is a bet on the next decadethat tokens will stop being passive ledger entries and start being the agents that act on the ledger.

A token that can run its own exchange, its own governance, its own risk-management logic, is a different kind of object than the one we have been composing against. It is a program with a balance. It is, in the fullest sense, computable.

The reference implementation is open source. Our first live deployment is on Paxeer Mainnet. The standard is yours to build against.