PAX-28 Token Standard

Native fungible token standard for ArgusVM — Rust-inspired syntax, built-in overflow protection, and register-optimised gas

Overview

PAX-28 is the native fungible token standard for HyperPaxeer, designed for ArgusVM’s register-based architecture and the ArgLang smart-contract language. It provides the same functional surface as ERC-20 but with compile-time safety guarantees, optimised gas on register hardware, and Rust-inspired ergonomics.

ArgusVM Optimised

Designed for register-based execution — no stack overhead

Built-in Safety

Automatic overflow/underflow protection at the language level

ArgLang Native

Statically typed, Rust-inspired syntax that compiles to AVM bytecode

---

Interface

All HPX-28 compliant tokens must implement:

trait HPX28 {
    pub view fn name() -> bytes;
    pub view fn symbol() -> bytes;
    pub view fn decimals() -> u256;
    pub view fn total_supply() -> u256;
    pub view fn balance_of(owner: address) -> u256;
    pub view fn allowance(owner: address, spender: address) -> u256;

    pub fn transfer(to: address, amount: u256) -> bool;
    pub fn transfer_from(from: address, to: address, amount: u256) -> bool;
    pub fn approve(spender: address, amount: u256) -> bool;
}

Events

event Transfer(from: address indexed, to: address indexed, amount: u256);
event Approval(owner: address indexed, spender: address indexed, amount: u256);

---

Reference Implementation

contract HPX28Token {
    state name: bytes;
    state symbol: bytes;
    state decimals: u256;
    state total_supply: u256;
    state balances: Map<address, u256>;
    state allowances: Map<address, Map<address, u256>>;

    event Transfer(from: address indexed, to: address indexed, amount: u256);
    event Approval(owner: address indexed, spender: address indexed, amount: u256);

    init(name_: bytes, symbol_: bytes, decimals_: u256, initial_supply: u256) {
        name = name_;
        symbol = symbol_;
        decimals = decimals_;
        total_supply = initial_supply;
        balances[msg.sender] = initial_supply;
        emit Transfer(address(0), msg.sender, initial_supply);
    }

    pub view fn name() -> bytes { return name; }
    pub view fn symbol() -> bytes { return symbol; }
    pub view fn decimals() -> u256 { return decimals; }
    pub view fn total_supply() -> u256 { return total_supply; }
    pub view fn balance_of(owner: address) -> u256 { return balances[owner]; }
    pub view fn allowance(owner: address, spender: address) -> u256 {
        return allowances[owner][spender];
    }

    pub fn transfer(to: address, amount: u256) -> bool {
        require(to != address(0), "transfer to zero address");
        require(balances[msg.sender] >= amount, "insufficient balance");
        balances[msg.sender] = balances[msg.sender] - amount;
        balances[to] = balances[to] + amount;
        emit Transfer(msg.sender, to, amount);
        return true;
    }

    pub fn transfer_from(from: address, to: address, amount: u256) -> bool {
        require(from != address(0), "transfer from zero address");
        require(to != address(0), "transfer to zero address");
        require(balances[from] >= amount, "insufficient balance");
        require(allowances[from][msg.sender] >= amount, "insufficient allowance");
        balances[from] = balances[from] - amount;
        balances[to] = balances[to] + amount;
        allowances[from][msg.sender] = allowances[from][msg.sender] - amount;
        emit Transfer(from, to, amount);
        return true;
    }

    pub fn approve(spender: address, amount: u256) -> bool {
        require(spender != address(0), "approve to zero address");
        allowances[msg.sender][spender] = amount;
        emit Approval(msg.sender, spender, amount);
        return true;
    }
}

---

Storage Model

PAX-28 uses Keccak256-based storage slot hashing, adapted for ArgusVM’s register architecture:

• Simple state variables get sequential slots (counter → slot 0, owner → slot 1)
• Maps use keccak256(key || base_slot) for slot computation
• Nested maps (e.g. allowances) apply hashing recursively: keccak256(spender || keccak256(owner || base_slot))

Gas Costs

Operation	Gas (Estimated)
balance_of() / allowance()	~251 gas (KECCAK256 + SLOAD)
transfer()	~21,000 gas
transfer_from()	~35,000 gas
approve()	~46,000 gas

Gas costs are lower than ERC-20 because register-based execution eliminates stack push/pop overhead for every intermediate value.

---

Differences from ERC-20

Aspect	ERC-20	HPX-28
Language	Solidity (function, mapping)	ArgLang (fn, Map, -> return types)
Overflow	Requires SafeMath or Solidity 0.8+ checks	Built into language — all arithmetic reverts on overflow
VM	Stack-based EVM	Register-based ArgusVM (32 x 256-bit registers)
Compilation	Solidity → EVM bytecode	ArgLang → AVM bytecode (.avm)
Storage hashing	keccak256(key . slot) (concatenation with period padding)	keccak256(key || slot) (direct concatenation)

---

Optional Extensions

HPX-28 Capped

pub view fn cap() -> u256;

pub fn mint(to: address, amount: u256) {
    require(total_supply + amount <= cap, "cap exceeded");
    // mint logic
}

HPX-28 Burnable

pub fn burn(amount: u256) {
    require(balances[msg.sender] >= amount, "insufficient balance");
    balances[msg.sender] -= amount;
    total_supply -= amount;
    emit Transfer(msg.sender, address(0), amount);
}

HPX-28 Mintable

pub fn mint(to: address, amount: u256) {
    require(msg.sender == minter, "only minter");
    balances[to] += amount;
    total_supply += amount;
    emit Transfer(address(0), to, amount);
}

---

Security Considerations

• Overflow protection is automatic — no SafeMath needed
• Zero-address checks prevent accidental token burns
• Approval race condition: set allowance to 0 before changing, or use increase_allowance() / decrease_allowance() extensions
• Reentrancy: follows checks-effects-interactions pattern — state changes before any external interaction

---

Cross-Chain Compatibility

PAX-28 is not bytecode-compatible with ERC-20 (different VM architecture). Cross-chain bridges must implement explicit translation:

1. Lock HPX-28 tokens on HyperPaxeer
2. Bridge translates to ERC-20 format
3. Mint equivalent ERC-20 on destination chain
4. Reverse: burn ERC-20, unlock HPX-28

The CrossVerse Bridge handles this translation natively.

---

Status

Field	Value
Standard	HPX-28
Status	Draft
Category	Token Standard
Network	HyperPaxeer

Resources

ArgusVM Architecture

Register set, ISA, gas model, and bytecode format

Smart Contracts

Deploy contracts on HyperPaxeer