Skip to main content
peaqOS runs on five layers. The Economics 2.0 contract set (machine registry, subscriptions, price oracle, trust validator staking) is what new machines activate against. The Tokenomics 1.0 registry and staking contracts still serve machines onboarded before 2026-09-01. Both sets live on as UUPS upgradeable proxies. is LayerZero V2; follow ERC-4337; and low-level , batch, and WPEAQ operations are peaq chain .

Architecture

  • Which set a client talks to is a configuration choice: the SDKs enter Tokenomics 2.0 mode when you pass tokenomics20: { deploymentId } (JS) or tokenomics20=Tokenomics20Config(deployment_id=...) (Python); the CLI reads TOKENOMICS_DEPLOYMENT_ID. Apart from the 2.0 EventRegistry, which event submission reads from EVENT_REGISTRY_ADDRESS, Economics 2.0 addresses are not environment variables: they ship inside the SDK’s deployment record and are verified against InfoDesk.peer(role) before every write.
  • Core contracts use UUPS upgradeable proxies (OpenZeppelin 5.x) with ERC-7201 namespaced storage. Future upgrades preserve state.
  • ( by IdentityRegistry) and (minted by MachineNFT) are separate ERC-721 spaces with independent tokenId sequences linked by machineId. See Machine NFT.
  • The Tokenomics 1.0 IdentityRegistry implements ERC-8004 for DID-anchored machine metadata. The serves JSON Machine Cards for Economics 2.0 machines only and has none for Tokenomics 1.0 machines. See Machine Card.

peaq mainnet addresses

Economics 2.0 (peaq mainnet)

Deployment record peaq-mainnet (chain ID 3338). All are ERC-1967 proxies. Economics 2.0 writes go through the SDKs and the CLI. The seven contracts marked SDK are the roles the SDK snapshot carries: before a write the SDK checks their bytecode and verifies the six other than InfoDesk against InfoDesk.peer(role). Of the other eleven, the SDKs resolve OperatorRegistry and RemoteBondSettlement through InfoDesk.peer(role) for a Solana onboarding and read EventRegistry (2.0) for event submission; the rest are used by peaq’s own services. Apart from the 2.0 EventRegistry, which event submission reads from EVENT_REGISTRY_ADDRESS, none of them are environment variables. The PEAQ token the bond is paid in is not a deployed contract: InfoDesk.peaqToken() resolves to the native-balance precompile 0x0000000000000000000000000000000000000809.

Tokenomics 1.0 (peaq mainnet)

Set these in your environment. The reads them from fromEnv() / from_env(). The SDK constructor still requires them in Tokenomics 2.0 mode, although activation reads none of them.

Core

Precompiles

Optional

Base mainnet addresses

Needed when bridging into peaq from . Pass as baseNftAddress / base_nft_address to bridgeNft / bridge_nft.

Solana mainnet addresses

Economics 2.0 (Solana mainnet)

Eleven Anchor programs. Protocol chain ID 5, LayerZero EID 30168. All keep the deployment wallet as upgrade authority and as administrator of each program’s root account. Configuration: bonds are sized from peaq’s tier prices mirrored to Solana (0.02/0.02 / 0.20 / $40 for Entry, Basic and Pro), native SOL and bridged PEAQ whitelisted as currencies, bridging on and relocation off. On the peaq side MachineBridgeAdapter has the Solana store PDA registered as its LayerZero peer. Sync messages use the trust validator node in both directions. The SDKs and CLI reach InfoDesk, MachineBridgeAdapter, MachineRegistry, MachineStateAndSync, EventRegistry, MachineSubscriptionTerminal, PriceOracle and SubscriptionTokenProvisionPool (deployment record solana-mainnet in the JS SDK, the Solana half of peaq-mainnet in the Python SDK): management, reads and event submission for machines homed on Solana, and onboarding (CLI 0.0.19, both SDKs 0.11.2, terminal-first in seven stages). CoordinationFeeCollector, TreasuryPool and TrustValidatorStaking are deployed but not configured in the SDKs; nothing the SDKs call depends on them. MachineSubscriptionTerminal owns the SubscriptionTerminal account the programs read for onboarding and event eligibility; which subscription account the SDKs read is selected by the deployment record’s reader setting (terminal). With the SDKs and CLI the bond for a Solana machine is paid on Solana through MachineSubscriptionTerminal, in PEAQ or in USDC swapped to exactly the bond, and peaq’s trust validator node books it onto peaq. See Onboard a machine on Solana and Omni-chain for the status of each capability.

Agung testnet addresses

Economics 2.0 (agung testnet)

Deployment record agung-2026-08-28 (chain ID 9990). Same seven SDK roles as mainnet. Agung has no paired 2.0 MCR, so monetization calls fail with DEPLOYMENT_UNAVAILABLE there.

Tokenomics 1.0 (agung testnet)

Tokenomics 1.0 path. These contracts serve machines already onboarded under Tokenomics 1.0 on , and the SDK constructor still requires the core addresses. New machines on agung activate against the Economics 2.0 set above.
The contract surface matches mainnet; only the deployed addresses differ.

Core

Precompiles

Identical to mainnet: same fixed addresses on every peaq runtime.

Optional

Bridging cannot be exercised on agung. LayerZero deprecated the agung endpoint (EID 40299): DVNs and executors are no longer active, so bridgeNft / bridge_nft cannot relay, and there is no agung MachineNFTAdapter. Exercise the bridge on peaq mainnet and Base mainnet only.

Economics 2.0 contracts

MachineRegistry

The 2.0 machine registry: one ERC-721 per machine where the token ID is the machine ID (uint256(keccak256(abi.encode(machineType, credentialSubject)))), plus the machine’s DID document (controller, verification methods, authentication, service endpoints). Standard ERC-721 transfers and approvals are how a machine changes owner. New machines are minted inside MachineStateAndSync.activateMachine; the registry’s other mint paths (legacy reissue, relocation import) are callable only by MachineStateAndSync and MachineBridgeAdapter. There is no public mint. SDK methods: getMachineOwner, computeMachineId, transferMachine, safeTransferMachine, approveMachine, setMachineApprovalForAll, setMachineController, setMachineVerificationMethods, setMachineAuthentication, setMachineServiceEndpoints

MachineStateAndSync

Orchestrates the one-transaction activation (activateMachine, activateMachineWithUsdt), voluntary suspend and resume, per-machine and protocol-wide pause flags, and relocation. Never holds tokens. SDK methods: activateMachine, activateMachineWithUsdt, previewMachineActivation, suspendMachine, resumeMachine, getMachineActivationState, getMachineAvailability

MachineSubscription

Prices and collects the tier bond (requiredPeaqAmount(tier)), stores each machine’s subscription (tier, period, bonded amount), applies grace and runoff, and tracks bonding reward and voucher credits. A renewal can also change the tier, up or down, once the period has ended (Grace or Runoff), priced at the full bond of the new tier; a tier change is refused while the machine is Active. The contracts on peaq mainnet support it, but the published peaq-mainnet deployment record does not enable tier selection on renewal, so the CLI and the SDKs refuse a tier there (RENEWAL_TIER_UNSUPPORTED) and today a renewal keeps the stored tier. The allowance spender for PEAQ bonds. Settlement functions are called by the trust validator node. SDK methods: activateExistingMachine, renewMachine, previewMachineRenewal, getMachineSubscription

InfoDesk

Owner-set protocol parameters (tier prices in USD, grace and runoff durations, epoch length, fee rates, burn and treasury addresses), the peer registry the SDK verifies against (the owner can set or clear a role; a cleared role reads as the zero address), the trust validator allowlist, and peaqToken(), which is set once and cannot be re-pointed.

PriceOracle

Daily currency prices committed by trust validator nodes (commitPrices), read by MachineSubscription to convert USD tier prices to PEAQ. Public read: getLatestPrice(bytes32 currency).

CrossChainMirror and MachineBridgeAdapter

Record the machine’s home chain and carry the messages between peaq and Solana. Sync messages (mirror pushes such as the link push, and revenue reports from Solana) go through the trust validator node by default: the sending adapter emits TvRelayQueued with a nonce per destination, and the node delivers each message to the other chain’s adapter (tvReceive on peaq, tv_receive on Solana) in nonce order. Only an allowlisted trust validator can deliver. No LayerZero fee is paid on this route; the node pays the delivery transaction. The owner can switch a message type to LayerZero (on peaq InfoDesk.setTransport, or setChainTransport for one destination; on Solana set_sync_route); there is no automatic failover between the two. The relocation handshake and peaq’s Retire broadcast always travel over LayerZero V2, and the node refuses them on both chains. InfoDesk.isBridgingEnabled() is true and isMachineRelocationEnabled() is false, so relocation stays disabled and the SDKs expose status reads only. For a machine homed on Solana, MachineBridgeAdapter applies the owner’s link push coming back from Solana; lastAppliedMirrorPushSeq(5, 0, machineId, MACHINE_REGISTRY_KEY) at or above the push’s sequence is what the SDK calls complete. SDK methods: getMachineRelocationStatus

SubscriptionTokenProvisionPool

Pays out the PEAQ bond for bonds collected on another chain, and settles --payment usdt / activateMachineWithUsdt / renewMachine with payment: "usdt" when a USDT token is configured in the pool. On peaq mainnet none is set, so USDT payments fail. The allowance spender for USDT.

TrustValidatorStaking, CoordinationFeeCollector, ExecutionCostReserve, EventRegistry (2.0), MachineMigrationHub

Live on mainnet. EventRegistry (2.0) is the write target of submitEvent / submit_event / peaqos qualify event when EVENT_REGISTRY_ADDRESS points at it; the other four are operated by peaq or reserved for later releases and not exposed in the SDKs or the CLI. See Economics 2.0.

Tokenomics 1.0 contracts

These serve the machines onboarded before 2026-09-01. A client constructed with tokenomics20 never writes to them; without tokenomics20 the SDKs still run the legacy registerMachine / register_machine flow against them (legacy flow).

IdentityRegistry

Central machine identity registry of Tokenomics 1.0. Mints an ERC-721 Identity NFT to each machine on and orchestrates through IdentityStaking.stakeFor(). Implements ERC-8004 for DID-anchored machine metadata; the MCR API has no Machine Card for these machines. themselves live on the peaq DID precompile (W3C DID), written by the SDK via writeMachineDIDAttributes. Tracks per-machine status (None → Pending → Verified / Rejected / Deactivated). Supports self-registration and proxy registration. SDK methods: registerMachine, registerFor Key state: minBond (currently 1 PEAQ), nextMachineId, operatorOf, machineStatus

IdentityStaking

Bond token storage. Tokens are staked at registration time via stakeFor() and held permanently; no withdrawal path is exposed. Only authorized callers (IdentityRegistry) can initiate stakes. Supports pause / unpause by owner. SDK interaction: Indirect. registerMachine / registerFor route the bond through here automatically.

EventRegistry

On-chain store for revenue (type 0) and activity (type 1) . Gates event submission on (a) the machine being registered in IdentityRegistry, and (b) the machine being bonded in IdentityStaking. Authorization rule: msg.sender must be the Identity NFT holder, the machine , or the (see Events: Authorization). Stores a keccak256 of the raw data; payloads stay off-chain. SDK methods: submitEvent, batchSubmitEvents Concept: Events

MachineNFT

ERC-721 representing a machine’s financial profile, bridged through the separate LayerZero V2 MachineNFTAdapter. Minted in a separate mintNft call after registration: the Machine NFT tokenId is independent from the Identity NFT tokenId. tokenURI points at the MCR API’s /metadata/{token_id} route, which serves Economics 2.0 machines only; there is no public MCR for Tokenomics 1.0 machines. SDK methods: mintNft, tokenIdOf Concept: Machine NFT

Cross-chain contracts

These are the Tokenomics 1.0 Machine NFT bridge. Economics 2.0 machines relocate through MachineBridgeAdapter and CrossChainMirror instead, which is disabled today.

MachineNFTAdapter (peaq)

Wraps MachineNFT for LayerZero V2 bridging. Lock/unlock pattern: locks the on peaq while the mirror exists on the destination chain. Needed only when bridging from peaq. Peer: Base (EID 30184). The Solana lane is closed: its ONFT program HraxgdzfcAi3AnxRP5sGSrXGAb9ZT1tZTMNuh9vQLxTu is closed on Solana mainnet (its program data no longer exists), and the SDKs bridge to Base only. SDK methods: bridgeNft / bridge_nft when source is "peaq"

MachineNFTBase (Base)

Standard ONFT721 on Base. Burn/mint pattern: NFT is burned when bridged back to peaq. Needed when bridging from Base. SDK methods: bridgeNft / bridge_nft when source is "base" (pass the address as baseNftAddress / base_nft_address)

ERC-4337 smart accounts

MachineAccountFactory

CREATE2 factory for deploying MachineSmartAccount BeaconProxy instances. Standard ERC-4337 flow: smart accounts run through the canonical EntryPoint at 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 (same address across all networks). SDK methods: deploySmartAccount / deploy_smart_account, getSmartAccountAddress / get_smart_account_address

MachineSmartAccount

The shared BeaconProxy implementation behind deployed smart accounts. Handles owner/machine RBAC and broad machine execution authority. Users never interact with the implementation directly; calls go to the deployed proxy.

AdminFlags

Optional peaq-chain contract read by the MCR API server (not the SDK). Holds admin-set flags that modify responses: per-machine negative_flags and trust-level overrides. MCR consumers see the adjusted score in their API response. When the contract isn’t configured, contracts.admin_flags on GET /ready reports true (the optional check is skipped) and the service serves unmodified MCR.

Precompiles (peaq chain)

LayerZero endpoints

Used by the bridge adapters. You don’t set these directly; the SDK handles them. The SDK exports the peaq and Base EIDs as LAYER_ZERO_EIDS (JS) / LAYERZERO_EIDS (Python); the Solana EID is not in that constant.

Upgrade pattern

All Economics 2.0 contracts, and all Tokenomics 1.0 core contracts (IdentityRegistry, IdentityStaking, EventRegistry, MachineNFT), use OpenZeppelin UUPS upgradeable proxies with ERC-7201 namespaced storage. Implementation slots are kept distinct by namespace, so future upgrades won’t collide with existing state. MachineSmartAccount uses a BeaconProxy pattern: a single implementation upgrade simultaneously applies to every deployed smart account.

See also

Install

Wire the contract addresses into .env for the SDK.

SDK reference

Every method that reads or writes these contracts.

API reference

Off-chain reads derived from the on-chain state.