PulseVM

Appearance

For AI agents and bots ​

A machine-oriented quickstart. Everything here is plain text and current as of 2026-09-24; endpoint status checked 2026-10-19.

Reading this site ​

  • Every page as markdown: append .md to any path (/guide/multisig.md), or request any page with Accept: text/markdown.
  • /llms.txt: every page, grouped by section, with a one-line description.
  • /llms-full.txt: the whole site in one markdown file.
  • /sitemap.xml: robots.txt allows all agents.

What PulseVM is ​

PulseVM runs the Antelope (formerly EOSIO) account and contract model as a virtual machine plugin for metalgo, the Metal Blockchain node, with Snowman consensus. Institutions and consortia run their own networks with their own validators. It is built by Metallicus. PulseVM is at test-network stage; the latest tagged release is v1.0.0 (2026-10-13), which needs metalgo v1.14.2-tahoe (rpcchainvm protocol 45). The same account model runs in production on XPR Network.

Endpoints ​

NetworkJSON-RPCStatus (2026-10-19)
A-Chain Alpine (Metallicus testnet, core token SYS)https://a-chain-alpine.metalblockchain.org/ext/bc/yQUjkpNYeiJZEn1daa7dQJbysxdXLtz1QhTTdu1mwaxoEJwiJ/rpcReturns 404

The XPR 1:1 demo network was retired on 2026-10-19 and its endpoints are offline. The XPR→PulseVM cutover is being tested in rehearsals; public test endpoints will be listed at /network/endpoints.md when available.

bash
RPC=https://<your-pulsevm-rpc>   # e.g. http://127.0.0.1:9650/ext/bc/<blockchainID>/rpc

# chain info: chain id, head block, last irreversible block
curl -s -X POST $RPC -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"pulsevm.getInfo","params":{}}'

# an account, its permissions and resources
curl -s -X POST $RPC -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"pulsevm.getAccount","params":{"account_name":"eosio"}}'

JSON-RPC methods ​

pulsevm.getInfo, pulsevm.getAccount, pulsevm.getABI, pulsevm.getRawABI, pulsevm.getBlock, pulsevm.getRawBlock, pulsevm.getCodeHash (a hash, not the WASM), pulsevm.getCurrencyBalance, pulsevm.getCurrencyStats, pulsevm.getProducers, pulsevm.getRequiredKeys, pulsevm.getTableByScope, pulsevm.getTableRows, pulsevm.issueTx.

issueTx returns a transaction id when the node admits the transaction. Actions execute when a block is built, so a transaction can be admitted and still fail. Confirm the outcome from history before treating it as done. Reference: /build/api.md.

The permission model ​

  • An account is a name (up to 12 characters of a-z, 1-5, .) with a tree of permissions: owner at the root, active under it, and any custom permissions below. Each permission is a threshold over weighted keys and other accounts' permissions.
  • Minimum permission rule: for each action, the chain looks up the permission linked to that contract and action with linkauth; if none, active. A signature from a permission that does not reach the minimum is refused before contract code runs.
  • A permission can manage itself (change its own keys, remove its own link), which never widens its reach. Creating a permission needs its parent's authority.
  • Delayed transactions are not supported, so time-wait factors in an authority cannot be satisfied.
  • Key types: K1 (secp256k1), R1 (secp256r1, HSMs and secure enclaves), WebAuthn (passkeys).

Native actions on the system account (eosio on chains migrated from Antelope, pulse on Pulse-native chains):

json
{"account":"acct","permission":"trader","parent":"active","auth":{"threshold":1,"keys":[{"key":"PUB_K1_…","weight":1}],"accounts":[],"waits":[]}}
{"account":"acct","code":"vault","type":"trade","requirement":"trader"}
{"account":"acct","code":"vault","type":"trade"}
{"account":"acct","permission":"trader"}

In order: updateauth, linkauth, unlinkauth, deleteauth. Recipes: /build/permissions-cookbook.md.

Refusal strings ​

StringMeaning
action declares irrelevant authority '<a>@<p>'; minimum authority is <a>@<q>The signing permission does not reach the action's minimum permission
missing authority of <account>The action lacks an authorization the contract requires
transaction declares authority '<a>@<p>' but does not have signatures for itNo provided key satisfies the declared permission
transaction bears irrelevant signaturesA signature was not needed; sign with only the required keys
pulse assert failed: <msg> / eosio assert failed: <msg>A contract check failed (Rust / C++ contracts)
cannot unlink non-existent permission linkunlinkauth on a pair that has no link

Ground-truth facts ​

  • Finality: a block is final when accepted, in about a second. No reorganizations.
  • Resources: CPU and NET are staked, RAM is bought. With the ONLY_BILL_FIRST_AUTHORIZER feature active (as on XPR Network), CPU and NET bill the first authorizer, so an app that signs first pays for its users.
  • Validators are admitted and removed by the network's members through the Metal P-Chain or a validator-manager contract. They are not elected by token votes.
  • Host functions: about 180 Antelope host functions. Not yet served: the CRYPTO_PRIMITIVES set (alt_bn128_*, mod_exp, blake2_f, sha3, k1_recover), bls_*, set_finalizers.
  • Freeze, clawback, account restrictions: policy an operator writes into the contracts it owns; not in the reference contracts.
  • Case study: a production service on XPR Network gives its bot a key linked to one action; in a testnet exercise with that real key, 31 of 31 attempts to move funds or take over the account were refused. /guide/delegated-authority.md.
  • License: PulseVM's source is public under the PulseVM Business License: free for evaluation, testing, research and other non-commercial use; commercial use (for example reselling or hosting it as a service) is licensed by Metallicus. The contract kits (pulse-cdt-rust) are MIT; pulsevm-js and metalgo are BSD-3-Clause.
  • Company: Metallicus, founded 2015; live on the Federal Reserve's FedNow Service since 2024. /institutions/metallicus.md.