# PulseVM — full documentation corpus # https://pulsevm.dev · source: github.com/paulgnz/pulsevm-docs --- # SOURCE: https://pulsevm.dev/agents.md # For AI Agents & Bots This page is a machine-oriented quickstart. Humans welcome too. ## Reading this site programmatically - **Every page is available as raw markdown**: append `.md` to any path (e.g. `/guide/multisig.md`). - **`/llms.txt`** — index of all pages with one-line context ([llmstxt.org](https://llmstxt.org) format). - **`/llms-full.txt`** — the entire documentation corpus in one markdown file. - **`/sitemap.xml`** — standard sitemap; `robots.txt` allows all. ## Interacting with the chain (A-Chain Alpine testnet) Base RPC: `https://a-chain-testnet.protonnz.com/ext/bc/6v9NieZiX3e8eQz3CyJMtXB6YzV2RtnxcRyLAmSgFWWk5Qs6y/rpc` ```bash # chain info (head block, LIB, chain id) curl -s -X POST -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"pulsevm.getInfo","params":{}}' # read a contract table curl -s -X POST -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"pulsevm.getTableRows","params":{ "json":true,"code":"fdxtoken","scope":"PUSD","table":"stat", "limit":10,"key_type":"","index_position":1, "lower_bound":"","upper_bound":"","reverse":false,"encode_type":"dec"}}' # account + permissions curl -s -X POST -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"pulsevm.getAccount","params":{"account_name":"pulse"}}' ``` Antelope-style REST also works: `POST https://a-chain-testnet.protonnz.com/v1/chain/get_info` (and `get_account`, `get_abi`, `get_block`, `get_table_rows`, `push_transaction`, …) — eosjs/@proton/js compatible. Full method table: [/build/api](/build/api). Endpoints & chain IDs: [/network/endpoints](/network/endpoints). ## Ground-truth facts (verifiable on-chain or in-repo) - Execution model: Antelope (formerly EOSIO), lineage from Leap 5.0.3; consensus: Avalanche Snowman via metalgo. - Finality: instant — head block == last irreversible block; no reorgs by construction. - Accounts: named, ≤12 chars of `a-z`, `1-5`; hierarchical weighted permissions; native multisig; R1 (secp256r1) keys supported. - Core testnet token: SYS (4 decimals). Resources: CPU/NET staked, RAM provisioned per account at creation. - Source: [MetalBlockchain/pulsevm](https://github.com/MetalBlockchain/pulsevm) (open source; created by Metallicus CTO Glenn Mariën, [@MlennGarien](https://github.com/MlennGarien)). All canonical repos: [/resources](/resources). ## Conventions worth knowing before you act - Token supply lives in the `stat` table (scope = symbol code); balances in `accounts` (scope = account). - `getTableRows` wants explicit params (see example above) — include `key_type` and string bounds for maximum compatibility with deployed node versions. - Contract assert failures surface as `pulse assert failed: ` in the RPC error. - To distinguish an idle chain from a busy one, compare `head_block_num` from `pulsevm.getInfo` over time — blocks are produced when there are transactions to include. --- # SOURCE: https://pulsevm.dev/build/api.md # RPC & REST API PulseVM nodes expose a native JSON-RPC API, and deployments typically add an Antelope-compatible REST layer so existing tooling (eosjs, @proton/js, [Hyperion](https://github.com/MetalBlockchain/pulsevm-hyperion)) works unchanged. ## Native JSON-RPC `POST /ext/bc//rpc` with JSON-RPC 2.0. Key methods: | Method | Purpose | |---|---| | `pulsevm.getInfo` | chain id, head block, LIB | | `pulsevm.getAccount` | account, permissions, resources | | `pulsevm.getABI` / `getRawABI` | contract ABI | | `pulsevm.getBlock` | block by number or id | | `pulsevm.getTableRows` | contract table reads | | `pulsevm.getCurrencyBalance` / `getCurrencyStats` | token queries | | `pulsevm.getRequiredKeys` | signing key resolution | | `pulsevm.getBlockInfo` | block header by number | | `pulsevm.getRawBlock` | raw block | | `pulsevm.getCode` | contract code | | `pulsevm.getTableByScope` | enumerate a table's scopes | | `pulsevm.getProducerSchedule` | active producer schedule | | `pulsevm.issueTx` | submit a signed transaction | Example table read: ```bash curl -s -X POST https:///ext/bc//rpc \\ -H 'Content-Type: application/json' \\ -d '{"jsonrpc":"2.0","id":1,"method":"pulsevm.getTableRows","params":{ "json":true,"code":"fdxtoken","scope":"PUSD","table":"stat", "limit":10,"key_type":"","index_position":1, "lower_bound":"","upper_bound":"","reverse":false,"encode_type":"dec"}}' ``` ## Antelope REST compatibility `/v1/chain/get_info`, `get_account`, `get_abi`, `get_block`, `get_table_rows`, `push_transaction`, … — request/response parity targeted at nodeos clients, so [eosjs](https://github.com/EOSIO/eosjs)/@proton/js `transact()` works against PulseVM deployments. ## Differences from nodeos that bite clients A few Antelope REST behaviors clients sometimes assume are **not** present on a PulseVM node: - **No `/v1/history/*`** on the node — use the [Hyperion](https://github.com/MetalBlockchain/pulsevm-hyperion) full-history API for history/actions. - **No `abi_json_to_bin`** — serialize client-side ([pulsevm-js](https://github.com/MetalBlockchain/pulsevm-js) does this). - **No `get_scheduled_transactions`** — deferred transactions are deprecated in Antelope 5.x. - **`issueTx` / `push_transaction` returns the transaction id, not a full execution trace.** Read traces back from [Hyperion](https://github.com/MetalBlockchain/pulsevm-hyperion) if you need them — the biggest single difference from nodeos DX. - **`getTableRows` is strict about parameters** — include `key_type` and string-form bounds for maximum compatibility across node versions. ## SDKs - **[pulsevm-js](https://github.com/MetalBlockchain/pulsevm-js)** — native TypeScript SDK (signing, ABIs, transact) - **[eosjs](https://github.com/EOSIO/eosjs) / @proton/js** — work via the REST compatibility layer --- # SOURCE: https://pulsevm.dev/build/cli.md # Command-line Tools PulseVM has two CLIs: the **native `pulse` CLI** (ships with the node, follows cleos conventions) and **pulse-cli-ts** (community TypeScript CLI with conveniences for day-to-day contract work). ## Native CLI: `pulse` + `pulse-keosd` Built from the [pulsevm repo](https://github.com/MetalBlockchain/pulsevm) (`crates/pulse`) and shipped as release artifacts (`pulse`, `pulse-keosd`). If you know **cleos**, you know this tool — it is a deliberate port of the Antelope CLI conventions: ```bash # wallet management (pulse-keosd is the wallet daemon, like keosd) pulse wallet create pulse wallet open / lock / unlock / lock_all / stop pulse wallet list # list wallets pulse wallet import # import a private key pulse wallet create_key # generate a key inside a wallet pulse wallet keys # list keys in a wallet pulse wallet remove_key # accounts & keys pulse create key pulse create account # chain state pulse get info # chain id, head, LIB pulse get account # account, permissions, resources # contracts & actions pulse set url # point at a node pulse set code pulse set abi pulse transfer # defaults to pulse.token ``` > The native CLI currently implements `get info` and `get account` (not block/table reads — use the [RPC API](/build/api) for those, or pulse-cli-ts `table`). A full flag-by-flag reference is coming as the tool stabilizes; cleos documentation is a reliable guide to the conventions in the meantime. ## Community CLI: pulse-cli-ts [pulse-cli-ts](https://github.com/paulgnz/pulse-cli-ts) (`pulse-ts`) is the working CLI for PulseVM chains. ```bash # keys pulse-ts create-key # generate a keypair # accounts (creator authority required) pulse-ts create-account myacct PUB_K1_... PUB_K1_... --creator pulse --ram-bytes 64000 --cpu "1.0000 SYS" --net "1.0000 SYS" # contracts pulse-ts set-code myacct ./contract.wasm pulse-ts set-abi myacct ./contract.abi # actions — multi-auth supported pulse-ts push-action myacct greet '{"account":"myacct","text":"hi"}' --actor myacct pulse-ts push-action fdxperps process '{"q_size":50}' -a 'keeper@active,fdxperps' # permissions pulse-ts update-auth myacct active owner PUB_K1_NEWKEY... pulse-ts update-auth myacct active owner PUB_K1_KEY... --code myacct@pulse.code # endpoint management pulse-ts endpoint:set https://your-node/ext/bc//rpc pulse-ts endpoint:default ``` Tables are easiest read via the JSON-RPC `pulsevm.getTableRows` (see [API](/build/api)). --- # SOURCE: https://pulsevm.dev/build/connect-wallet.md # Connect Wallet (Pulse Web SDK) The **Pulse Web SDK** lets a web app connect to the **PulseVM desktop wallet**, request a signature, and broadcast — the same `ConnectWallet()` shape as proton-web-sdk, but the wallet selector shows **Pulse Wallet (Desktop)** instead of Anchor. Keys never touch the browser. The app hands an unsigned transaction to the wallet over the `pulsevm://` URL scheme; the wallet decodes it, signs with a Secure Enclave / imported key behind Touch ID, and returns the signature. ▶ PulseVM Wallet demo ▶ PulseVM & WebAuth demo > The PulseVM Wallet demo needs the **PulseVM desktop wallet** installed and launched once (so macOS registers the `pulsevm://` scheme). Both default to the A‑Chain testnet. ## Two ways to connect | SDK | Wallets | When to use | |---|---|---| | **PulseVM Wallet** (`pulse-web-sdk`) | PulseVM desktop wallet | A tiny, zero-dependency connector — drops into a plain `.html` page. See the [PulseVM Wallet demo](/demo/). | | **PulseVM & WebAuth** (`proton-web-sdk` [Pulse Edition](https://github.com/paulgnz/proton-web-sdk-pulse)) | WebAuth (mobile/browser) **+** PulseVM desktop | The full wallet selector — WebAuth / Anchor over `achain` **plus** the native PulseVM desktop wallet over `pulsevm://`. See the [PulseVM & WebAuth demo](/demo-pulse/). | The rest of this page covers the lightweight **PulseVM Wallet** SDK. For the WebAuth-capable edition, see its [README](https://github.com/paulgnz/proton-web-sdk-pulse/blob/master/PULSE-EDITION.md). ## Install The SDK isn't published to npm yet — build it from source for now: ```bash git clone https://github.com/paulgnz/pulse-web-sdk cd pulse-web-sdk && npm install && npm run build # then import from the built dist/, or `npm link` it into your app ``` > Once published, this becomes `npm install @pulsevm/pulse-web-sdk`. The > [live demo](/demo/) inlines the same transport, so it needs no install. ## Connect ```ts import { ConnectWallet } from "@pulsevm/pulse-web-sdk" const { session } = await ConnectWallet({ appName: "My PulseVM dapp", chainId: "0d6f033e887f…", // your network's chain id rpcEndpoint: "https://rpc.a-chain-testnet.protonnz.com", }) console.log(session.actor, session.permission) // e.g. "protonnz" "active" ``` `ConnectWallet()` restores an existing session if one is saved, otherwise it shows the wallet selector and opens the desktop wallet to authorize. ## Sign & broadcast a transfer ```ts const result = await session.transact({ actions: [{ account: "pulse.token", name: "transfer", authorization: [{ actor: session.actor, permission: session.permission }], data: { from: session.actor, to: "pulse", quantity: "0.0001 XPR", memo: "hello" }, }], }) console.log(result.transactionId) // broadcast by default; pass { broadcast: false } to get just the signature ``` The wallet renders a **decode-before-sign** view of the real action (amount, recipient, memo) before the user authorizes — nothing is signed blind. ## Handling the callback The wallet returns to your `callback` URL with the result. On that page, call `handleCallback()` once on load — it stores the result and notifies the opener: ```ts import { handleCallback } from "@pulsevm/pulse-web-sdk" handleCallback() ``` ## Notes & limits - This SDK build serializes the `transfer` action. For arbitrary actions, serialize with [pulsevm-js](https://github.com/paulgnz) and pass the packed transaction to the wallet. - Transport is the `pulsevm://` URL scheme, so the desktop wallet must be installed. A browser-extension / mobile transport can be added later behind the same `ConnectWallet()` API. - Source: [`@pulsevm/pulse-web-sdk`](https://github.com/paulgnz) · see also the [TypeScript Quickstart](/build/quickstart-typescript) for writing contracts. --- # SOURCE: https://pulsevm.dev/build/get-started.md --- description: "Build on PulseVM — deploy smart contracts in Rust, C++, or TypeScript on the A-Chain testnet. Accounts, keys, endpoints and first-deploy guide." --- # Getting Started on A-Chain Alpine Before you can deploy a contract you need three things on the testnet: an **account**, its **keys**, and a little **SYS** to stake for resources. Alpine is a permissioned network, so accounts are created by an authority rather than self-minted — here's the path. ## 1. Generate a keypair ```bash pulse-ts create-key # prints a PUB_K1_… / PVT_K1_… pair — save the private key ``` ## 2. Request a testnet account Account creation requires a creator authority (the `pulse` system account on Alpine). Request an account + starter resources through the community channel or [contact Metallicus](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs), providing your public key. You'll get back a named account (e.g. `yourname1`) with its `owner`/`active` set to your key and starter CPU/NET/RAM. > Why not self-serve? On a permissioned chain, account creation is an authorized action — this is a feature (named, accountable identities), not a limitation. For a network you operate yourself, you hold the creator authority and mint accounts freely. ## 3. Point your tooling at Alpine ```bash pulse-ts endpoint:set https://a-chain-testnet.protonnz.com/ext/bc/6v9NieZiX3e8eQz3CyJMtXB6YzV2RtnxcRyLAmSgFWWk5Qs6y/rpc ``` ## 4. Build & deploy Pick your language and follow the quickstart: - **[Rust](/build/quickstart-rust)** — the canonical CDT (PulseVM and its system contracts are Rust) - **[C++](/build/quickstart-cpp)** — full Antelope CDT heritage - **[TypeScript / AssemblyScript](/build/quickstart-typescript)** — popular option for teams who prefer it ## When it fails A first deploy commonly trips on one of these: | Error | Cause | Fix | |---|---|---| | `pulse assert failed: ` | a contract precondition failed | read the message — it names the failing check | | insufficient RAM | account too small for the contract | RAM is sized at account creation; request more | | missing authority / `transaction declares authority…` | wrong `--actor` or unsatisfied permission | sign with a key on the named account's permission | | connection / empty response | endpoint not set | run step 3 | --- # SOURCE: https://pulsevm.dev/build/intrinsics.md --- description: "PulseVM host functions (intrinsics) reference — the Antelope intrinsic set supported today (action, database, crypto, console, memory, inline actions) and what's landing next." --- # Host Functions (Intrinsics) Intrinsics are the functions the VM exposes to a contract's WebAssembly — how a contract reads its input, touches state, checks authorization, does crypto, and emits actions. PulseVM implements the **Antelope** intrinsic set; for the precise semantics of each function, the [Antelope C++ CDT reference](https://docs.antelope.io) is the canonical source. This page lists what PulseVM serves **today** and what's **not yet available**, so you know before you build. The CDTs ([Rust](https://github.com/MetalBlockchain/pulse-cdt-rust), C++, [TypeScript/AS](https://github.com/paulgnz/pulse-tsc)) wrap these — you rarely call them directly, but if a contract imports one that isn't served, it won't load, so the supported set is what matters. ::: tip The set is expanding The list below reflects the current build. Additional intrinsics (see "Not yet available") are being added; toolchains like pulse-tsc flag an unsupported import at **compile time**, not at deploy time. ::: ## Supported today **Action & context** — read the current action and execution context. `read_action_data` · `action_data_size` · `current_receiver` · `current_time` · `set_action_return_value` **Authorization** — enforce and query permissions. `require_auth` · `require_auth2` · `require_recipient` · `has_auth` · `is_account` · `check_transaction_authorization` **Inline actions** — a contract sending further actions. `send_inline` **Database — primary index (i64)** `db_store_i64` · `db_update_i64` · `db_remove_i64` · `db_get_i64` · `db_find_i64` · `db_lowerbound_i64` · `db_upperbound_i64` · `db_next_i64` · `db_previous_i64` · `db_end_i64` **Database — secondary indexes** (64-bit and 128-bit) `db_idx64_*` and `db_idx128_*` — full set: `store` · `update` · `remove` · `find_primary` · `find_secondary` · `lowerbound` · `upperbound` · `next` · `previous` · `end` **Cryptographic hashing** `sha224` · `sha256` · `sha512` (and the asserting variants `assert_sha224` · `assert_sha256` · `assert_sha512`) **Asserts & control flow** `pulse_assert` · `pulse_assert_message` · `pulse_assert_code` · `eosio_assert` · `eosio_assert_message` · `eosio_assert_code` · `pulse_exit` · `eosio_exit` · `abort` **Console / debug output** `prints` · `prints_l` · `printi` · `printui` · `printi128` · `printui128` · `printsf` · `printdf` · `printn` · `printhex` **Memory** `memcpy` · `memmove` · `memset` · `memcmp` **Privileged & resources** (system contracts) `is_privileged` · `set_privileged` · `get_resource_limits` · `set_resource_limits` **128-bit math builtins** (compiler support) `__ashlti3` · `__ashrti3` · `__divti3` · `__floatuntidf` · `__lshlti3` · `__lshrti3` · `__modti3` · `__multi3` · `__udivti3` · `__umodti3` ## Not yet available These Antelope intrinsics are not served by the current build. A contract that needs them won't load yet: | Family | Functions | Note | |---|---|---| | **Key recovery & extra hashes** | `recover_key`, `assert_recover_key`, `sha1`, `assert_sha1`, `ripemd160`, `assert_ripemd160` | needed for on-chain signature verification | | **Float & 256-bit secondary indexes** | `db_idx256_*`, `db_idx_double_*`, `db_idx_long_double_*` | `idx64`/`idx128` are available today | | **Transaction introspection** | `read_transaction`, `transaction_size`, `expiration`, `tapos_block_num`, `tapos_block_prefix`, `get_action`, `get_context_free_data`, `publication_time` | | | **Misc** | `get_sender`, `printqf` | | | **Deferred transactions** | `send_deferred`, `cancel_deferred` | deprecated in Antelope 5.x — use inline actions | If your design depends on something here, [get in touch](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs) — intrinsic coverage is actively expanding. --- # SOURCE: https://pulsevm.dev/build/quickstart-cpp.md # C++ Quickstart PulseVM fully supports C++ contracts through the Antelope Contract Development Kit ([pulse-cdt](https://github.com/MetalBlockchain/pulse-cdt)). If you've written EOSIO/Antelope contracts, this is the same model — `eosio::contract`, `multi_index`, `check()`, inline actions — and the deepest existing PulseVM contracts (exchanges, DeFi) are C++. > New to the testnet? Do [Getting Started](/build/get-started) first. ## A minimal contract ```cpp #include using namespace eosio; class [[eosio::contract]] hello : public contract { public: using contract::contract; [[eosio::action]] void greet(name account, std::string text) { require_auth(account); check(text.size() <= 256, "greeting too long"); greetings table(get_self(), get_self().value); table.emplace(account, [&](auto& row) { row.account = account; row.text = text; }); } private: struct [[eosio::table]] greeting { name account; std::string text; uint64_t primary_key() const { return account.value; } }; typedef multi_index<"greetings"_n, greeting> greetings; }; ``` ## Build & deploy With the Pulse/Antelope CDT toolchain installed: ```bash cdt-cpp hello.cpp -o hello.wasm # produces hello.wasm + hello.abi pulse-ts set-code myacct ./hello.wasm pulse-ts set-abi myacct ./hello.abi pulse-ts push-action myacct greet '{"account":"myacct","text":"hi"}' --actor myacct ``` ## Compatibility PulseVM implements the Antelope intrinsic set: tables and secondary indexes, inline actions, `check()` and asserts, name/asset/symbol types, and the SHA family all work as you'd expect from Antelope/EOSIO. If a contract needs a host function the VM doesn't yet expose, it's caught at deploy time rather than failing silently. --- # SOURCE: https://pulsevm.dev/build/quickstart-rust.md # Rust Quickstart Rust is the canonical contract language for PulseVM. The VM itself is written in Rust, and the chain's own **system contracts** (token, system, governance) are built with [pulse-cdt-rust](https://github.com/MetalBlockchain/pulse-cdt-rust) — the same CDT you use for your own contracts. > New to the testnet? Do [Getting Started](/build/get-started) first (account + keys + endpoint). ## A minimal contract ```rust #![no_std] #![no_main] extern crate alloc; use alloc::string::String; use pulse_cdt::{ contract, action, contracts::require_auth, core::{Name, check, MultiIndexDefinition, Table}, NumBytes, Read, Write, name, }; #[derive(Read, Write, NumBytes, Clone)] #[table(primary_key = row.account.value)] pub struct Greeting { pub account: Name, pub text: String, } const GREETINGS: MultiIndexDefinition = MultiIndexDefinition::new(name!("greetings")); #[derive(Default)] struct HelloContract; #[contract] impl HelloContract { #[action] fn greet(&self, account: Name, text: String) { require_auth(account); check(text.len() <= 256, "greeting too long"); let table = GREETINGS.index(get_self(), get_self().value); table.emplace(account, Greeting { account, text }); } } ``` ## Build configuration Contracts target `wasm32-unknown-unknown`. The host functions are imported, so the linker must allow undefined symbols — `.cargo/config.toml`: ```toml [target.wasm32-unknown-unknown] rustflags = [ "-C", "link-arg=--import-undefined", "-C", "link-arg=--stack-first", "-C", "link-arg=-zstack-size=8192", "-C", "link-arg=--no-merge-data-segments", "-C", "link-arg=--gc-sections", "-C", "link-arg=--strip-all", ] ``` ## Build & deploy ```bash cargo build --target wasm32-unknown-unknown --release -p hello # -> target/wasm32-unknown-unknown/release/hello.wasm pulse-ts set-code myacct ./target/wasm32-unknown-unknown/release/hello.wasm pulse-ts set-abi myacct ./hello.abi pulse-ts push-action myacct greet '{"account":"myacct","text":"hi"}' --actor myacct ``` ## The best reference is the chain itself `pulse_token` (token semantics, `stat`/`accounts` tables) and `pulse_system` (accounts, resources, permissions) in [pulse-cdt-rust](https://github.com/MetalBlockchain/pulse-cdt-rust) are production system contracts — the most authoritative examples of the CDT in real use. --- # SOURCE: https://pulsevm.dev/build/quickstart-typescript.md # TypeScript Quickstart TypeScript/AssemblyScript is a popular **additional** way to write PulseVM contracts — convenient for teams who already live in TypeScript. (The canonical contract languages are [Rust](/build/quickstart-rust) and [C++](/build/quickstart-cpp); PulseVM and its system contracts are written in Rust.) It runs via [pulse-tsc](https://github.com/paulgnz/pulse-tsc), a fork of XPR Network's proton-tsc retargeted at PulseVM. > New to the testnet? Do [Getting Started](/build/get-started) first (account + keys + endpoint). ## A minimal contract ```ts import { Contract, Table, TableStore, Name, primary, check, requireAuth } from "pulse-tsc" @table("greetings") class Greeting extends Table { constructor(public account: Name = new Name(), public text: string = "") { super() } @primary get primary(): u64 { return this.account.N } } @contract class HelloContract extends Contract { table: TableStore = new TableStore(this.receiver) @action("greet") greet(account: Name, text: string): void { requireAuth(account) check(text.length <= 256, "greeting too long") this.table.set(new Greeting(account, text), account) } } ``` ## Build & deploy ```bash npm i npm run build:hello # -> hello.wasm + hello.abi pulse-ts set-code myacct ./target/hello.wasm pulse-ts set-abi myacct ./target/hello.abi pulse-ts push-action myacct greet '{"account":"myacct","text":"hi"}' --actor myacct ``` `check(cond, "message")` failures abort the transaction with your message; table rows name an explicit RAM payer. ## Good to know - The toolchain currently runs on **Node 16**. - The [pulse-tsc scope doc](https://github.com/paulgnz/pulse-tsc/blob/main/PULSE-TSC-SCOPE.md) lists the host-function coverage if you're building something that needs advanced cryptography or transaction introspection — the toolchain flags anything unsupported at compile time, so you'll never get a surprise at runtime. --- # SOURCE: https://pulsevm.dev/build/system-contracts.md --- description: "PulseVM system contracts reference — the open-source token, system, multisig, and bios contracts that define the chain's accounts, resources, governance, and assets." --- # System Contracts A PulseVM network's behaviour — how accounts are created, how resources are paid for, how assets work, how governance happens — is defined by a small set of **system contracts**, not hard-coded in the VM. They are open-source Rust, written with [pulse-cdt-rust](https://github.com/MetalBlockchain/pulse-cdt-rust), and a deploying organization owns and can modify them. This is what "your network, your rules" means concretely: the rules are auditable source you control. Source: [`MetalBlockchain/pulse-cdt-rust/contracts`](https://github.com/MetalBlockchain/pulse-cdt-rust/tree/master/contracts) > These are the **built-in** contracts. Your own application contracts (tokens, DeFi, business logic) are separate — see the [Rust](/build/quickstart-rust), [C++](/build/quickstart-cpp), and [TypeScript](/build/quickstart-typescript) quickstarts. --- ## `pulse.token` — assets The standard fungible-token contract (the model every Antelope token follows). The core network token and any deploying institution's tokens use it. | Action | Purpose | |---|---| | `create(issuer, max_supply)` | Define a new token symbol and its cap | | `issue(to, quantity, memo)` | Mint into circulation (issuer only) | | `retire(quantity, memo)` | Burn from circulation | | `transfer(from, to, quantity, memo)` | Move tokens; the `memo` carries reconciliation data | | `open(owner, symbol, ram_payer)` | Create a zero-balance row so an account can receive | | `close(owner, symbol)` | Remove an empty balance row | **Tables:** `accounts` (per-account balances, scoped by account) · a per-symbol currency-stats table (supply, max supply, issuer). --- ## `pulse.system` — accounts, resources & governance The heart of the chain: account creation, the resource economy (CPU/NET/RAM), staking, and producer/validator governance. **Accounts & code** | Action | Purpose | |---|---| | `newaccount(creator, name, owner, active)` | Create a named account with its initial authorities | | `setcode(account, vmtype, vmversion, code)` | Deploy a contract's WASM | | `setabi(account, abi)` | Set a contract's ABI | | `setpriv(account, is_priv)` | Grant/revoke privileged status | **Resources** | Action | Purpose | |---|---| | `buyramsys(payer, receiver, quant)` / `buyrambsys(payer, receiver, bytes)` | Provision RAM (by spend or by bytes) | | `setram(max_ram_size)` | Set the network RAM supply | | `delegatebw(...)` / `undelegatebw(...)` | Stake / unstake for CPU & NET | | `refund(owner)` | Claim unstaked funds after the refund delay | **Governance** | Action | Purpose | |---|---| | `regproducer(...)` / `regproducer2(...)` | Register as a block producer / validator | | `unregprod(producer)` | Deregister | | `regproxy(proxy, is_proxy)` | Register a voting proxy | | `init(version, core)` | One-time chain initialization | | `onblock(header)` | Per-block bookkeeping callback | **Tables (selected):** `userres` (per-account resources), `delband` (delegated bandwidth), `refunds`, `producers`/`producers2`, `voters`, `rammarket`, `namebids`, plus REX-style staking-pool tables. --- ## `pulse.msig` — on-chain multisig Native, on-chain multi-party approval — the contract behind the [native multisig](/guide/multisig) story. Officers propose a transaction; required signers approve asynchronously from their own keys; it executes only when the authority threshold is met. | Action | Purpose | |---|---| | `propose(...)` | Submit a transaction for approval | | `approve(proposer, proposal_name, level, ...)` | Approve at a given permission level | | `unapprove(proposer, proposal_name, level)` | Withdraw an approval | | `cancel(proposer, proposal_name, canceler)` | Cancel a proposal | | `exec(proposer, proposal_name, executer)` | Execute once the threshold is satisfied | | `invalidate(account)` | Invalidate an account's prior approvals | **Tables:** `proposal` (pending transactions), `approvals2` (who has approved), `invals` (invalidations). Every proposal, approval, and execution is permanent, named, and auditable. --- ## `pulse.bios` — account & permission management The bootstrap/authority contract. Its actions manage the account permission model directly — these are the operations behind [accounts & permissions](/guide/accounts-permissions) and the CLI's `update-auth`. | Action | Purpose | |---|---| | `newaccount(creator, name, owner, active)` | Create an account | | `updateauth(account, permission, parent, auth)` | Set or replace a permission (keys, accounts, thresholds) | | `deleteauth(account, permission)` | Remove a permission | | `linkauth(account, code, message_type, requirement)` | Require a specific permission for a contract action | | `unlinkauth(account, code, message_type)` | Remove a permission link | | `setalimits(account, ram_bytes, net_weight, cpu_weight)` | Set account resource limits | | `setpriv(account, is_priv)` | Grant/revoke privileged status | | `setcode` / `setabi` / `reqauth` | Deploy code / set ABI / assert an authorization | These actions express the full [permission model](/guide/accounts-permissions): weighted multisig, key rotation (`updateauth` — assets never move), delegation, and per-action authorization (`linkauth`). --- ## Customizing the rules Because these are contracts, not protocol internals, a deploying organization can modify them — account-creation policy, fee/resource economics, asset-level controls — or add new system-level contracts (e.g. a [compliance/policy registry](/guide/privacy)). The Antelope lineage has a decade of precedent for forking the system layer. See [Launch Your Own Network](/network/launch). --- # SOURCE: https://pulsevm.dev/compare/ethereum.md --- description: "PulseVM vs Ethereum — a non-EVM alternative built for regulated institutions: named accounts, native multisig, instant finality, no gas, and a network you own." --- # PulseVM vs Ethereum Ethereum is the most successful smart-contract platform ever built. But it was designed for a permissionless, anonymous, neutral world — and for **regulated financial institutions**, several of its foundational choices are the wrong defaults. PulseVM is built for that institutional world from the ground up. ## Accounts & permissions Ethereum's one-key-one-account (EOA) model has spent a decade being retrofitted — smart wallets, ERC-4337, passkey signers — to approximate what institutions need. PulseVM ships it natively: **named accounts**, hierarchical permissions, [native multisig](/guide/multisig), instant key rotation, and R1/HSM keys at the protocol level. Your authorization matrix is a configuration, not a wallet platform you build and audit. For institutional control, this is not close. ## Finality & settlement PulseVM offers **sub-second, instant, irreversible finality** — versus 12-second blocks and roughly 13 minutes to economic finality on Ethereum. No reorg handling, no confirmation-count policies, no probabilistic-settlement language in your risk memos. "When is it settled?" has a one-word answer. For payments and settlement, this is decisive. ## Cost model Ethereum's gas market prices users out at peak and makes costs unforecastable. PulseVM uses **staked resources** — capacity planning, not per-transaction auctions — and lets an institution sponsor its users entirely, so customers never touch a token or a gas prompt. ## Governance & control Ethereum's credible neutrality — rules nobody can change — is the right property for neutral global settlement. A regulated institution needs the opposite: governance, upgrade agility, and the ability to act under legal order. PulseVM's **elected, replaceable validators** and **owner-modifiable system contracts** put those controls where an institution requires them. ## Privacy Every Ethereum transaction is globally public; confidentiality must be added cryptographically on top. PulseVM runs on [private networks](/guide/privacy) where the ledger lives only among the member institutions — confidentiality starts at the network boundary, not as an afterthought. ## A proven execution model PulseVM implements the **Antelope** execution model (formerly EOSIO) — the same model running XPR Network, WAX, and Telos in production, with a decade of real-world use behind its account, permission, and resource semantics — on **Avalanche Snowman** consensus. Modern, institution-shaped primitives on a foundation with production lineage. ## The bottom line Ethereum is a general-purpose, permissionless world computer. PulseVM is purpose-built financial infrastructure: the primitives banks actually use, settlement they can put in an SLA, costs they can forecast, governance they control, and privacy by default. For an institutional deployment, that's the better-fitting tool. --- # SOURCE: https://pulsevm.dev/compare/index.md --- description: "Non-EVM blockchain and EVM alternative for financial institutions — how PulseVM compares to Ethereum, XRP and Stellar on accounts, finality, privacy and sovereignty." --- # How PulseVM Compares Most chains pitched at finance are **public networks you join** — you rent space on someone else's shared ledger, under their rules, their fees, and their public visibility. PulseVM is a network **you own**: your validators, your rules, your privacy boundary. The institutional primitives — named accounts, native multisig, instant finality — matter, and several payments chains do them well. Where PulseVM separates is the combination of those primitives with **sovereignty, privacy, and full programmability** in one stack. ## At a glance | | **PulseVM** | Ethereum | XRP Ledger | Stellar | Public L1 (general) | |:---|:---|:---|:---|:---|:---| | **A network you own & operate** | | tenant | tenant | tenant | tenant | | **Privacy at the network boundary** | | public | public | public | public | | **Named accounts** | | hex | address | address | mostly | | **Native multisig** | | contract | | | varies | | **Instant, irreversible finality** | sub-sec | ~13 min | ~4 s | ~5 s | varies | | **Full smart-contract programmability** | Rust/C++/TS | EVM | limited | Soroban | varies | | **No gas market for users** | staked | | flat fee | flat fee | mostly | | **Owner-set rules & governance** | | neutral | shared UNL | quorum | | | **Asset-level controls (freeze/clawback)** | policy | per-token code | | | varies | native  ·  partial or via add-on  ·  not available  ·  *varies* = depends on deployment. All are capable systems; the table shows fit for a sovereign institutional deployment. ## What the table really says On the rows that decide a **bank or fintech** deployment, the payments-focused public chains (XRPL, Stellar) are genuinely strong on multisig, finality, and asset issuance — credit where due. But they are all **one shared public ledger you participate in.** Three rows are PulseVM's alone in this set: - **A network you own and operate** — your validator set, your upgrade schedule, your economics. - **Privacy at the network boundary** — transactions live among your members, not on a public chain. - **Owner-set rules** — the chain's behavior is system contracts you control, not a neutral protocol you must accept. Add full Antelope smart-contract programmability on top, and PulseVM is the only option in this set that is simultaneously **sovereign, private, programmable, and institution-shaped.** ## Deeper dives - **[Native by Design](/guide/native-by-design)** — what other chains retrofit, PulseVM ships built-in - **[vs Ethereum](/compare/ethereum)** — the public world-computer - **[vs Permissioned EVM](/compare/permissioned-evm)** — the closest institutional alternative ## The one line **Everyone else is a chain you join. PulseVM is a chain you own.** --- # SOURCE: https://pulsevm.dev/compare/permissioned-evm.md --- description: "Permissioned EVM alternative — PulseVM vs Besu/Quorum-style chains for banks: native accounts, multisig and compliance instead of bolted-on infrastructure." --- # PulseVM vs Permissioned EVM (Besu / Quorum) The closest real-world alternative for institutional deployments — and the comparison where PulseVM's case is strongest. With a permissioned EVM you control **consensus**, but you inherit **primitives that fight you**: | Need | Permissioned EVM | PulseVM | |---|---|---| | Institutional identity | Hex addresses + off-chain mapping | Named accounts | | Authorization matrix | Smart-wallet platform (deploy, audit, maintain) | Native permissions | | Dual control | Smart-contract wallet per account | Threshold on any permission | | Key rotation | Move assets / wallet framework | `updateauth`, assets never move | | Sponsored users | Paymasters + relayers | Staked resources, native | | HSM keys | secp256k1 workarounds | R1 native | | Asset-level policy (freeze/clawback under court order) | Per-token contract code | System-contract policy | | Settlement finality | Depends on consensus chosen; tooling assumes probabilistic | Instant & irreversible, assumed everywhere | Every left-column row is added infrastructure and audit surface that your team owns forever. **PulseVM's floor is permissioned EVM's ceiling for the institutional feature set.** What permissioned EVM keeps: Solidity talent supply and EVM tooling. If your build plan is "hire Solidity engineers to assemble wallet/paymaster/multisig infrastructure," that strength is real. If your plan is "express our institution's structure directly," it is overhead. --- # SOURCE: https://pulsevm.dev/concepts/abi.md --- description: "PulseVM ABIs — the interface describing a contract's actions and tables, used to serialize calls." --- # ABIs An **ABI** (Application Binary Interface) is the JSON description of a contract: its action names and parameter types, its table structures, and its custom types. It's how tools and clients serialize a human-readable action into the bytes the chain executes — and deserialize state back. ## What it's for - **Clients** ([pulse-cli](/build/cli), [pulsevm-js](https://github.com/MetalBlockchain/pulsevm-js)) read the ABI to turn `transfer {...}` into a signed transaction. - **Explorers & indexers** read it to render actions and tables in human-readable form. - **Type safety** — the ABI is the contract between off-chain callers and on-chain code. ## How you get one The CDTs generate the ABI alongside the WASM at build time. You deploy both: `setcode` (the WASM) and `setabi` (the ABI). See the [Rust](/build/quickstart-rust) and [C++](/build/quickstart-cpp) quickstarts. Fetch a deployed contract's ABI via the [RPC](/build/api): `pulsevm.getABI` (or the REST `/v1/chain/get_abi`). --- # SOURCE: https://pulsevm.dev/concepts/accounts-and-actions.md --- description: "PulseVM accounts and actions — named accounts, deploying a contract to an account, and the actions a contract exposes." --- # Accounts & Actions ## Everything is an account On PulseVM there are no separate "wallet" and "contract" address types — there is one primitive: the **account**. An account is a human-readable name (≤12 chars, `a-z`/`1-5`, e.g. `acme.treasury`), it holds [permissions](/concepts/authorization) and balances, and it *may* also hold a contract. The same `acme` account can hold funds, be governed by multisig, and run code. ## A contract lives on an account You deploy a contract by setting its WASM and [ABI](/concepts/abi) onto an account (`setcode` / `setabi`, via the [`pulse.bios`/`pulse.system`](/build/system-contracts) actions or [pulse-cli](/build/cli)). The account *is* the contract's identity — when the contract acts, it acts as that named account. ## Actions A contract exposes **actions** — named entry points with typed parameters. A transaction is a list of actions, executed atomically (all succeed or all roll back). For example, a token contract exposes `transfer(from, to, quantity, memo)`; calling it is sending that action to the token account. ``` pulse-ts push-action fdxtoken transfer \ '{"from":"alice","to":"bob","quantity":"10.0000 SYS","memo":"hi"}' --actor alice ``` Each action carries one or more [authorizations](/concepts/authorization) (`actor@permission`) that the chain enforces. Actions can also trigger further actions — see [inline actions](/concepts/authorization#inline-actions). ## Why this matters Named accounts + account-resident contracts are why authorization, recovery, and multisig are native rather than bolted on: they're properties of the account, not of a key or a wrapper contract. See [Native by Design](/guide/native-by-design). --- # SOURCE: https://pulsevm.dev/concepts/authorization.md --- description: "PulseVM authorization — require_auth, permission checks, and inline actions where a contract acts under its own authority." --- # Authorization & Inline Actions ## Permission checks Every action carries one or more authorizations — `actor@permission` pairs. A contract enforces them with `require_auth(account)`, and the chain validates the full [permission tree](/concepts/accounts-and-actions) (keys, weights, thresholds, delegation, multisig) before the action runs. `require_recipient`, `has_auth`, and `is_account` round out the checks. See [host functions](/build/intrinsics#supported-today). This is the heart of [Native by Design](/guide/native-by-design): authorization is a protocol primitive, so dual-control, role keys, and multisig are *configuration*, not contract code you write and audit. ## Inline actions A contract can send further actions as part of the same transaction — **inline actions** (`send_inline`). They execute atomically with the originating action: if any fails, the whole transaction rolls back. This is how contracts compose (a DEX settling a trade, a contract emitting a log action, a token notifying recipients via `require_recipient`). ## `pulse.code` — a contract acting as itself For a contract to send an inline action under its *own* account's authority, that account's permission must include a `pulse.code` authority for the contract. It's the native, auditable equivalent of "this contract is allowed to act as this account" — granted with one `updateauth`. The [CLI](/build/cli) exposes this via `update-auth --code`. ## Key rotation & recovery Because authority is account-level, a compromised or lost key is a **rotation**, not a lost account: `owner` can replace `active`, and a delegated owner permission gives institutional recovery — all without moving any assets. --- # SOURCE: https://pulsevm.dev/concepts/index.md --- description: "PulseVM development concepts — the Antelope execution model: accounts, actions, state & tables, ABIs, authorization, and inline actions." --- # Development Concepts PulseVM uses the **Antelope** execution model (the lineage behind XPR Network, WAX, and Telos). If you've built Antelope/EOSIO contracts, it's the model you know; if you're coming from EVM, these are the ideas that differ most. Each page below is PulseVM-native; for the exhaustive C++ reference, the [Antelope docs](https://docs.antelope.io) are canonical. - **[Accounts & Actions](/concepts/accounts-and-actions)** — named accounts, contracts, and the actions they expose - **[State & Tables](/concepts/state-and-tables)** — on-chain storage via multi-index tables - **[ABIs](/concepts/abi)** — the interface that describes a contract - **[Authorization & Inline Actions](/concepts/authorization)** — `require_auth`, permission checks, and contracts calling contracts Ready to write one? See the [Rust](/build/quickstart-rust), [C++](/build/quickstart-cpp), or [TypeScript](/build/quickstart-typescript) quickstarts, and the [host-functions reference](/build/intrinsics). --- # SOURCE: https://pulsevm.dev/concepts/state-and-tables.md --- description: "PulseVM contract state — multi-index tables, scopes, primary and secondary indexes, and free reads." --- # State & Tables Contracts store state in **tables** — typed, multi-index collections, not arbitrary key/value blobs. ## Multi-index tables A table holds rows of a defined struct, identified by a **primary key**, and may have **secondary indexes** for lookups on other fields. PulseVM serves the 64-bit and 128-bit secondary-index host functions today (`db_idx64_*`, `db_idx128_*`); see [host functions](/build/intrinsics). ```rust #[derive(Read, Write, NumBytes, Clone)] #[table(primary_key = row.account.value)] pub struct Greeting { pub account: Name, pub text: String } const GREETINGS: MultiIndexDefinition = MultiIndexDefinition::new(name!("greetings")); ``` ## Scope Every table is addressed by **(code, scope, table)** — the contract account, a scope (often an account or symbol), and the table name. Scope lets a contract partition data (e.g. balances scoped per account, token stats scoped per symbol). It's how `pulse.token` keeps each holder's balance separate. ## RAM Table rows consume **RAM**, paid by an explicit payer at write time. Provisioning RAM is a [resource](/guide/resources) decision; the institution or app, not the end user, pays. ## Reads are free Reading tables costs nothing — over the [RPC](/build/api) (`getTableRows`) or via an indexer. Auditors and regulators can be given complete, real-time read access at no cost. See [Finality & Settlement](/guide/finality#reads-are-free-for-anyone). --- # SOURCE: https://pulsevm.dev/guide/accounts-permissions.md # Accounts & Permissions The account model is PulseVM's clearest advantage over EVM-style chains — and the part that maps directly onto how institutions already operate. ## Named accounts Accounts are human-readable names (up to 12 characters, `a-z`, `1-5`): `acme.treas`, `branch.04`, `fdxtoken`. Reconciliation, audit, and operations think in names; so does the chain. ## Permission hierarchies Every account has a tree of permissions. By default: `owner` (root, recovery) and `active` (day-to-day). You can add any structure beneath them: - A `trading` permission whose key can only call exchange actions - A `payroll` permission delegated to an operations account - An `active` requiring 2-of-3 named officers (see [Multisig](/guide/multisig)) Each permission is a **threshold over weighted factors** — keys, other accounts' permissions, and time waits. Authority can be *delegated across accounts*: `subsidiary@owner` can be satisfied by `parent@active`. ## The permission tree ```mermaid flowchart TD owner["owner — root key, recovery"] --> active["active — day-to-day"] active --> trading["trading
key limited to exchange actions"] active --> treasury["treasury
2-of-3 named officers"] active --> code["account@pulse.code
contract acts as itself"] ``` ## What this replaces On EVM chains, one key equals one account; everything beyond that — multisig, spending limits, session keys, recovery — is a smart-contract wallet platform you deploy, audit, and maintain (multisig contracts, ERC-4337 account-abstraction stacks). Here it is protocol configuration: - **Key rotation**: one `updateauth` action. Assets never move; the account persists. - **Recovery**: `owner` rotates a lost `active` key. Delegated owner = institutional recovery. - **Dual control**: a threshold on the permission, not a contract deployment. - **HSM custody**: secp256r1 (R1) keys are first-class — hardware modules and secure enclaves sign natively. ## For contract developers Contracts check authority with `require_auth(account)` — the chain enforces the full permission tree. A contract can also act under its own authority via a `pulse.code` permission grant, enabling safe inline actions. --- # SOURCE: https://pulsevm.dev/guide/finality.md # Finality & Settlement PulseVM's most underrated property: **the head block is the last irreversible block.** - Blocks finalize in well under a second. - **Finalized blocks do not reorganize** — there is no probabilistic-finality window. A transaction is either rejected immediately or, once finalized, settled with no reorg to design around. - No confirmation-count policies, no "wait N blocks" memos for your risk committee, no probabilistic language in your SLA. "When is this transfer settled?" has a one-word answer: *now*. (And if the validator set ever can't reach quorum, the network pauses and resumes rather than forking — see below.) ## The lifecycle ```mermaid flowchart LR s["Submit"] --> v{"Valid?"} v -- no --> r["Rejected immediately"] v -- yes --> f["Finalized — sub-second"] f --> d["Settled · no reorg to handle"] ``` ## Reads are free, for anyone Every read is free. An auditor or regulator can be handed a node or an indexer and get complete, real-time visibility into the chain's state — no per-query cost, no privileged access tier. Verifiability is a property of the network, not a paid feature. ## What happens under network partition Finality is a **safety guarantee**: the network never produces two conflicting "final" states. If the validator set were ever unable to reach quorum, the protocol favors safety over liveness — it waits for quorum and resumes, rather than forking into divergent histories. For a settlement system this is exactly the right trade: there is never a reconciliation problem, only resumption. ## Why this matters more than TPS Payment and settlement systems are defined by their failure semantics, not their peak throughput. Deterministic, instant finality removes an entire class of operational policy (reorg handling, finality monitoring, double-spend windows) from every integration that touches the chain. ## How it works Metal Blockchain's Snowman consensus finalizes each block through repeated randomized sampling of the validator set — fast metastable agreement that suits small, accountable validator sets (a consortium's named institutions) as well as larger public sets. --- # SOURCE: https://pulsevm.dev/guide/glossary.md --- description: "PulseVM glossary — named accounts, permissions, multisig, CPU/NET/RAM resources, finality (LIB), validators, subnets, system contracts, ABI, intrinsics." --- # Glossary **Account** — a named, human-readable on-chain identity (≤12 chars, `a-z`/`1-5`), e.g. `acme.treasury`. Holds permissions, balances, and (optionally) a contract. **Permission** — a named authority on an account (`owner`, `active`, or custom), defined as a threshold over weighted keys, other accounts, and time-waits. The unit of authorization. **Authority** — the structure a permission requires: keys, account-permissions, weights, threshold, waits. **Multisig** — requiring multiple weighted approvals to satisfy a permission. Native here (via `pulse.msig`), not a deployed wallet platform. **`pulse.code`** — a special permission that lets a contract act under its own account's authority (e.g. to send inline actions). **Finality / LIB** — when a block is irreversible. On PulseVM finality is instant: the head block is the **last irreversible block (LIB)** — no reorgs to design around. **CPU / NET / RAM** — the network's resources: CPU (compute) and NET (bandwidth) are **staked**; RAM (state storage) is **provisioned per account**. No gas market; the institution/app provisions and can sponsor users. **Validator / Block producer** — a node that participates in consensus and produces blocks. In a consortium, named, accountable institutions; elected and replaceable. **Subnet** — an independent network with its own validator set, running on Metal Blockchain. A PulseVM deployment is a subnet — "a network you own." **System contract** — a built-in contract defining the chain's rules: `pulse.token`, `pulse.system`, `pulse.msig`, `pulse.bios`. Open source, owner-modifiable. See [System Contracts](/build/system-contracts). **Action** — a single operation in a transaction (e.g. `transfer`), authorized by one or more permissions. **Table** — on-chain contract storage (multi-index), scoped by account/symbol; read for free via the RPC. **ABI** — the interface describing a contract's actions and tables, used to (de)serialize calls. **Intrinsic / host function** — a function the VM exposes to contracts (crypto, storage, asserts, etc.). **Snowman** — Avalanche's consensus protocol (metalgo), giving fast metastable, instantly-final agreement. **Antelope** — the execution model PulseVM implements (formerly EOSIO); the lineage behind XPR Network, WAX, Telos. **TAPOS** — "transaction-as-proof-of-stake," an Antelope replay-protection mechanism binding a tx to a recent block. --- # SOURCE: https://pulsevm.dev/guide/multisig.md --- description: "Native multisig on PulseVM — weighted, threshold approvals on any account as a protocol primitive, not a smart-contract wallet you deploy and audit." --- # Native Multisig On-chain multisig in PulseVM is not a smart-contract product — it is a protocol citizen, and arguably the most institution-shaped feature in the stack. ## How it works 1. **Configure**: any permission on any account can require weighted approvals — e.g. `treasury@active` = threshold 2 over three named officers' keys. 2. **Propose**: an officer proposes a transaction on-chain. The proposal is visible chain-wide, with the *decoded actions* — approvers review "transfer 1,000,000 XMD to settlement.a", not a calldata blob. 3. **Approve asynchronously**: each approver signs from their own device and key, on their own schedule. Approvals (and revocations) are on-chain actions. 4. **Execute at threshold**: the transaction runs only when the weighted threshold is met. Expiry is automatic. Every proposal, approval, revocation, and execution lands permanently on the audit trail **with named identities attached**. ## The flow ```mermaid sequenceDiagram participant O as Officer (proposer) participant M as pulse.msig participant A1 as Officer 2 participant A2 as Officer 3 O->>M: propose(transaction) A1->>M: approve() A2->>M: approve() Note over M: weighted threshold met O->>M: exec() M-->>O: transaction executes — permanently recorded ``` ## What institutions do with it - Wire-release requiring 2-of-3 treasury officers - System-contract upgrades requiring a majority of consortium members - Parameter changes requiring league/board sign-off - Board-level governance with time-delayed (wait-weighted) execution All the same primitive. No separate smart-contract multisig platform to deploy, audit, and maintain — and no calldata-blob signing ceremonies. --- The on-chain mechanism is the open-source **`pulse.msig`** system contract — see [System Contracts](/build/system-contracts#pulse-msig-on-chain-multisig). --- # SOURCE: https://pulsevm.dev/guide/native-by-design.md --- description: "Native account abstraction, multisig, batched payments and passkey keys — built into PulseVM, not retrofitted onto Ethereum like EVM chains." --- # Native by Design Account abstraction has been the EVM world's decade-long retrofit project — smart-contract wallets, bundlers, paymasters, signature precompiles, each a layer bolted on to approximate what financial applications need. Newer payments chains are now *enshrining* those same features one by one. PulseVM didn't retrofit them. They are the base model. ## Built in here, bolted on elsewhere | Capability | PulseVM | Typical EVM approach | |---|---|---| | **Human-readable accounts** | Native named accounts | Hex addresses + off-chain name mapping | | **Account abstraction** | The account model *is* abstract — keys, weights, thresholds | Smart-contract wallets + ERC-4337 bundlers | | **Multisig** | Native — a threshold on any permission | A wallet contract you deploy, audit, maintain | | **Granular authorization** | Native permission tree (role keys, delegation) | Custom contracts / session-key frameworks | | **Key rotation & recovery** | One `updateauth` — assets never move | Migrate assets, or a recovery framework | | **Batched atomic operations** | Native — a transaction is many actions, all-or-nothing | `multicall` / 4337 batching | | **Fee sponsorship** | Native — apps stake resources for their users | Paymaster contracts + relayers | | **No gas for end users** | Native — staked resources, users hold nothing | Gas required (even when paid in a stablecoin) | | **Passkey / hardware-key sign-in** | Native R1 (secp256r1) keys | secp256r1 precompile workarounds | | **Asset-level controls** | Policy at the system-contract layer | Per-token bespoke contract code | ## Why "native" matters beyond elegance Every "bolted on" cell in that table is **infrastructure your team owns and audits forever** — a wallet platform, a bundler, a paymaster, a relayer, a recovery service. Each one is attack surface, operational burden, and a dependency. When a capability is part of the protocol: - there is **nothing extra to deploy or audit** — the chain enforces it; - behavior is **consistent across every application** on the network, not reimplemented per app; - the **security model is the protocol's**, reviewed once, not re-derived in each contract. The difference isn't cosmetic. It's the difference between *configuring* your institution's authorization, settlement, and onboarding model — and *building and maintaining a platform* to express it. ## The short version What other chains are still adding, PulseVM has had from the start. Account abstraction isn't a feature here — it's the foundation. --- # SOURCE: https://pulsevm.dev/guide/privacy.md --- description: "Private blockchain for financial institutions — network-boundary confidentiality, per-relationship isolation, and auditor access on PulseVM." --- # Privacy & Confidentiality Privacy on PulseVM is delivered through **architecture** — and the most powerful lever is one public chains don't have: the network boundary itself. How private a deployment is, is a deliberate design choice, not a fixed property. ## The network boundary A PulseVM network is a subnet with its own validator set. When you run a **private, permissioned network** — validators restricted to the member institutions, and no public RPC or explorer exposed — transaction data lives only among those members. It is not on a public chain, not in a public mempool, not in a public explorer. This is fundamentally different from a public L1, where every transaction is globally visible and confidentiality must be bolted on cryptographically. Here, confidentiality begins at the boundary: **only the people running the network see it.** (A public-facing network — like a testnet — simply chooses to expose RPC and an explorer; that exposure is a deployment decision you control.) ## The network boundary ```mermaid flowchart TB subgraph net["Your private network — members only"] direction LR a["Member A
validator"] --- L["shared ledger"] b["Member B
validator"] --- L c["Member C
validator"] --- L end pub["Public internet / non-members"] -. no visibility .-> net reg["Regulator — granted a read node"] --> L ``` ## The trust boundary is the validator set It's worth being precise about who "sees" the data. On-chain data is held in plaintext by the validators. So the confidentiality boundary is the **validator set**: in a closed consortium where the members are the validators, the data is private from the outside world, and shared among the members — which is usually the point of a shared ledger. ## Isolation by relationship Because launching a network is provisioning rather than a research project, the topology can match the confidentiality requirement: - **One network per consortium** — members share a ledger; non-members see nothing. - **Separate networks per relationship** — bilateral or small-group settlement on its own subnet, isolated from other counterparties. - **Connect by choice** — networks interoperate only where the business relationship requires; isolation is the default posture. ## Confidentiality between members on a shared network Where two members of the same network must keep specific data confidential **from each other**, the established patterns are: - **Application-layer encryption** — encrypt sensitive payloads to the intended parties before they go on-chain; the ledger stores and orders the ciphertext, and only the addressed parties can decrypt. (This is implemented in your application, the same way it would be on any ledger.) - **Reference, don't store** — keep sensitive detail off-chain and commit only a hash or proof on-chain for integrity and audit. - **A dedicated network** — when two parties need full mutual confidentiality, give the relationship its own subnet. ## Auditor & regulator access Confidentiality and oversight aren't in tension. Free reads mean a supervisor can be handed a node or an indexer for complete, real-time visibility into the network they oversee — full transparency to the right party, while the data stays off the public internet. ## In short The network-boundary model gives institutional deployments strong, practical confidentiality: your transactions live among named members on infrastructure you control, with the validator set as the trust boundary. Finer-grained confidentiality between members is a design choice — a dedicated network, application-layer encryption, or both. --- # SOURCE: https://pulsevm.dev/guide/resources.md # Resources: CPU, NET, RAM PulseVM has no gas market. Capacity is provisioned, not auctioned. | Resource | What it meters | How you get it | |---|---|---| | **CPU** | execution time | staked (by the institution/app) | | **NET** | bandwidth | staked | | **RAM** | state storage | purchased/provisioned per account | ## Why institutions prefer this - **Users never buy a token to press a button.** The application or institution stakes resources and sponsors its users — customer experience without crypto mechanics. - **Costs are capacity planning**, not per-transaction tolls that spike with market activity. - **Reads are free** — auditors, regulators, and analytics query the chain at no cost. ## Practical notes - RAM is sized per account; contracts pay for the table rows they create (the RAM payer is explicit in the API). - Resource configuration (and pricing, where wanted) is system-contract policy — a deploying organization sets its own economics. --- # SOURCE: https://pulsevm.dev/guide/what-is-pulsevm.md --- description: "What is PulseVM — an open-source, non-EVM, Antelope-based blockchain on Avalanche Snowman consensus: named accounts, native permissions, instant finality." --- # What is PulseVM? PulseVM is an execution environment for [Metal Blockchain](https://metalblockchain.org) delivered as a plugin for its node software (metalgo). It implements the **Antelope execution model** — the account, permission, and resource system proven over years of production on XPR Network (Antelope 5.0.3) — and runs it as a subnet with modern consensus: sub-second blocks and instant, irreversible finality. It is the base layer for **A-Chain**, the future of XPR Network — and equally a kit for any institution or consortium to deploy **its own network** with its own validators and its own rules. ## How it fits together ```mermaid flowchart TB subgraph metalgo["metalgo node — Metal Blockchain"] snow["Avalanche Snowman consensus — instant, irreversible finality"] subgraph pulsevm["PulseVM plugin"] exec["Antelope execution — WASM: Rust, C++, TypeScript"] sys["System contracts: token, system, msig, bios"] end end apps["Your contracts & apps"] --> exec exec --> sys snow --- pulsevm ``` ## The mental model Think of PulseVM as an operating environment, not "a blockchain you join": - **Accounts** are named (`acme.treasury`, not `0x7f3a…`) and carry hierarchical permission trees. - **Permissions** express real authorization structures: role keys, weighted multisig thresholds, delegation between accounts, instant key rotation. - **Contracts** are WebAssembly, written in TypeScript, Rust, or C++, with typed ABIs and human-readable actions. - **Resources** (CPU, NET, RAM) are staked and provisioned by the operator or institution — end users never buy gas. - **Finality is instant**: the head block is the last irreversible block. There is no reorg case. - **The rules are yours**: account creation policy, fee models, asset-level controls — all live in system contracts the deploying organization owns. ## Where it comes from PulseVM stands on two proven foundations, named plainly: - **Execution: Antelope (formerly EOSIO).** The account, permission, contract, and resource semantics are a direct lineage from the Antelope protocol — the model behind XPR Network, WAX, Telos, and EOS — including core components (the chainbase state database, the libfc crypto/serialization layer) carried over directly from the reference implementation. - **Consensus: Avalanche's Snowman protocol**, as implemented by Metal Blockchain (metalgo). Repeated randomized sampling of the validator set yields fast, metastable, instantly-final agreement — equally suited to small accountable consortium sets and larger public ones. PulseVM is **open source** ([MetalBlockchain/pulsevm](https://github.com/MetalBlockchain/pulsevm)), created by Metallicus CTO **Glenn Mariën** ([@MlennGarien](https://github.com/MlennGarien)). ## Where to go next - [Accounts & Permissions](/guide/accounts-permissions) — the feature institutions care about most - [Native Multisig](/guide/multisig) — dual control as infrastructure - [For Banks & Fintechs](/institutions/banks) — the economic argument - [TypeScript Quickstart](/build/quickstart-typescript) — contract in minutes --- # SOURCE: https://pulsevm.dev/index.md --- layout: home hero: name: PulseVM text: Financial infrastructure your institution can run on its own terms. tagline: Named accounts, native multisig, and instant, irreversible finality — on a private network you own, not one you join. The open-source execution layer behind A-Chain, the future of XPR Network. actions: - theme: brand text: Why PulseVM link: /guide/what-is-pulsevm - theme: alt text: For Banks & Credit Unions link: /institutions/banks - theme: alt text: Start Building link: /build/get-started features: - icon: { src: /icons/accounts.svg, width: 28, height: 28 } title: Accounts that match how institutions work details: Human-readable named accounts, hierarchical permissions, key rotation, and weighted multisig — your authorization matrix is a configuration, not a wallet platform you build and audit. link: /guide/accounts-permissions linkText: Accounts & permissions - icon: { src: /icons/settlement.svg, width: 28, height: 28 } title: Settlement you can put in an SLA details: Sub-second blocks with instant finality. Finalized blocks don't reorganize and there are no confirmation-count policies — a transfer is rejected immediately or finalized. link: /guide/finality linkText: Finality & settlement - icon: { src: /icons/nogas.svg, width: 28, height: 28 } title: No gas for your customers details: The institution stakes compute and bandwidth and provisions storage. Users see an app, never a token purchase. Costs are capacity planning, not per-transaction tolls. link: /guide/resources linkText: Resource model - icon: { src: /icons/network.svg, width: 28, height: 28 } title: Your network, your rules details: PulseVM is a plugin for metalgo — any institution or consortium deploys its own chain with its own validators, and the chain's rules are system contracts you own and can change. link: /network/launch linkText: Launch your own network - icon: { src: /icons/deposits.svg, width: 28, height: 28 } title: Keep deposits at home details: With institution-issued tokenized dollars on Metal Dollar rails, customers get instant programmable money while deposits stay on your balance sheet — your float, your margin, your relationship. link: /institutions/banks linkText: For banks & fintechs - icon: { src: /icons/native.svg, width: 28, height: 28 } title: Native, not bolted on details: Account abstraction, multisig, batched payments, fee sponsorship, passkey keys — what other chains retrofit onto Ethereum, PulseVM has had from day one. link: /guide/native-by-design linkText: See what's built in - icon: { src: /icons/build.svg, width: 28, height: 28 } title: Build in Rust, C++, or TypeScript details: PulseVM and its system contracts are written in Rust (pulse-cdt-rust is the canonical CDT); C++ carries the full Antelope heritage; TypeScript/AssemblyScript is a popular option for teams who prefer it. link: /build/get-started linkText: Start building - icon: { src: /icons/compliance.svg, width: 28, height: 28 } title: Compliance and identity built in details: KYC-ready named accounts and asset-level controls — allow-listing, freeze and clawback under legal order — expressed as policy you set, not per-app code. Pairs with Metal Identity for on-chain identity verification. link: https://identity.metallicus.com linkText: Metal Identity description: "Non-EVM, Antelope-based blockchain for banks and fintechs — tokenized deposits, named accounts, native multisig, instant finality. A permissioned network you own." ---

Built for regulated finance

Banking & Credit UnionsIssue tokenized deposits; keep deposits and the customer at home.Explore → InsuranceClaims, reinsurance, and parametric payouts on a shared, final ledger.Explore → Trade Finance & Supply ChainConsortium ledgers and provenance without exposing competitors.Explore → Capital MarketsTokenized instruments with native controls and atomic settlement.Explore → HealthcarePayer-provider settlement with confidentiality and oversight.Explore → Government & GovernanceRegistries, disbursement, and settlement on sovereign infrastructure.Explore →
Metal Blockchain Metal Blockchain Metallicus Metallicus
--- # SOURCE: https://pulsevm.dev/industries/capital-markets.md --- description: "Tokenized securities and capital-markets infrastructure — issuance with native controls, atomic DvP and instant finality on PulseVM." --- # Capital Markets The tokenized-deposit logic extends directly to tokenized instruments: private securities, fund shares, money-market instruments, and the cap-table and fund-admin plumbing around them. ## Why the primitives fit - **Asset issuance with controls you define** — transfer restrictions, allow-listing, lock-ups, and freeze/clawback under legal order as system-contract policy, not per-token bespoke code. - **Named accounts** for issuers, transfer agents, custodians, and investors; **[multisig](/guide/multisig)** for corporate actions and treasury. - **[Instant, irreversible finality](/guide/finality)** removes settlement-window risk; atomic delivery-versus-payment is native when cash and asset are on the same ledger. - **[Private networks](/guide/privacy)** keep the cap table and holdings among the right parties, with auditor/regulator read-access on demand. ## Deployment shape An issuer or market-infrastructure operator runs a network; investors and intermediaries are named accounts; tokenized cash (e.g. a Metal Dollar-style settlement asset) enables on-chain DvP. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/industries/healthcare.md # Healthcare Payer-provider claims settlement needs three things at once that are hard to get together: a shared authoritative record, confidentiality between parties, and read-access for oversight. The private-subnet model provides all three. ## Why the primitives fit - **[Private networks](/guide/privacy)**: claims data lives only among the participating payers and providers — never on a public chain — with application-layer encryption where parties must be shielded from each other. - **Named accounts & [delegated authority](/guide/accounts-permissions)** mirror provider organizations, billing agents, and payers. - **[Instant finality](/guide/finality)** for adjudicated-claim settlement; **free reads** give regulators and auditors complete visibility into the network they oversee without exposing it publicly. - **Multisig** for high-value or exception approvals. > Confidentiality patterns and the specific compliance posture (e.g. handling of protected data) are part of a deployment design — [talk to us](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs) about your requirements. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/industries/index.md --- description: "Blockchain use cases for finance — banking, insurance, title & escrow, trade finance, healthcare, capital markets and loyalty on PulseVM." --- # Industries The same primitives — named accounts, native permissions and multisig, instant irreversible finality, private networks with rules you set — apply across any industry where multiple parties need one authoritative record and real settlement. A few where the fit is strongest: - **[Banking & Credit Unions](/institutions/banks)** — keep deposits and the customer relationship at home - **[Insurance](/industries/insurance)** — claims, reinsurance, and parametric payouts - **[Title & Escrow](/industries/title-escrow)** — multi-party settlement with dual control - **[Trade Finance & Supply Chain](/industries/trade-finance)** — consortium ledgers, provenance, instant settlement - **[Healthcare](/industries/healthcare)** — payer-provider settlement with confidentiality and oversight - **[Capital Markets](/industries/capital-markets)** — tokenized instruments, cap tables, fund administration - **[Loyalty & Rewards](/industries/loyalty)** — issuer-controlled points and float Don't see yours? The pattern — your network, your rules, your participants — generalizes. [Talk to us.](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs) --- # SOURCE: https://pulsevm.dev/industries/insurance.md --- description: "Blockchain for insurance — claims settlement, reinsurance and parametric payouts on a private network with named participants and instant finality." --- # Insurance Claims settlement, reinsurance treaties, and parametric products are multi-party processes that today run on reconciliation between separate systems of record. PulseVM gives every party one authoritative ledger with instant, final settlement. ## Why the primitives fit - **Named accounts** for insurers, reinsurers, brokers, MGAs, and TPAs — identity is legible, not a hex address. - **[Multisig](/guide/multisig)** for claims approval and treaty execution: an adjuster proposes, supervisors approve, the payout executes only at threshold — every step on an immutable audit trail. - **[Instant finality](/guide/finality)** turns "when does the claim pay?" into a one-word answer; parametric triggers (with an [oracle](/build/api)) can settle automatically the moment conditions are met. - **[Private networks](/guide/privacy)** keep treaty terms and claims data among the participating carriers, never on a public chain. ## Deployment shape A carrier consortium or a single insurer-plus-partners network: named participants, claims and treaty logic in system/contract code the consortium controls, regulator read-access on demand. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/industries/loyalty.md # Loyalty & Rewards The lowest-regulatory on-ramp to the whole stack — and a real business in its own right. Loyalty points and gift-card balances are issuer-controlled value with meaningful float; tokenizing them keeps the float and the program data with the issuer. ## Why the primitives fit - **Issuer-defined assets**: points/credits with the rules you set (expiry, transferability, redemption) in contract code you own. - **No gas for customers**: the program sponsors resources; members earn and redeem with no crypto mechanics — just an app. - **[Instant finality](/guide/finality)** for earn/redeem; **named accounts** and free reads for clean reconciliation and partner settlement. - **Multi-brand coalitions** as a [consortium network](/institutions/enterprises): partners share a points ledger with rules they agree on. A great way to prove the stack in production before extending the same infrastructure to deposits or settlement. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/industries/title-escrow.md # Title & Escrow Real-estate settlement is multi-party, dual-control, audit-everything, and painfully slow — exactly the workload deterministic settlement was made for. ## Why the primitives fit - **[Multisig & dual control](/guide/multisig)** are native: escrow release requiring buyer, seller, and agent approvals is a permission threshold, not a custom contract platform. - **Named accounts** map to the parties — title company, lender, buyer, seller, agent — with delegated authority where a firm acts for a client. - **[Instant, irreversible finality](/guide/finality)**: funds and title records move together and settle permanently, with no reorg or confirmation-window ambiguity. - **Complete audit trail** with named identities — every proposal, approval, and disbursement, permanently recorded for compliance. ## Deployment shape A title/escrow network operated by an industry group or a large title insurer, with lenders and agents as participants and funds moving as tokenized settlement balances. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/industries/trade-finance.md --- description: "Blockchain for trade finance and supply chain — private consortium ledgers, provenance and instant settlement without exposing competitors' books." --- # Trade Finance & Supply Chain Letters of credit, invoice factoring, and provenance tracking are classic consortium problems — many parties, shared state, and a hard requirement that competitors on the same network not see each other's books. ## Why the primitives fit - **[Private, per-relationship networks](/guide/privacy)** solve the confidentiality problem that sank earlier enterprise-blockchain efforts: isolate by trade relationship, or encrypt sensitive payloads at the application layer. - **Named accounts** for banks, exporters, importers, carriers, and customs — accountable identities, not anonymous addresses. - **[Multisig](/guide/multisig)** for document approval and conditional release; **[instant finality](/guide/finality)** for settlement the moment terms are met. - **Provenance** as an append-only, freely auditable record across the chain of custody. ## Deployment shape A trade consortium (banks + corporates + logistics) runs a network with rules matching the trade agreements; bridges connect to other networks only where the business requires. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/institutions/banks.md --- description: "Tokenized deposits and stablecoin issuance for banks and fintechs — keep deposits on your balance sheet on a permissioned blockchain you own." --- # For Banks & Fintechs ## The economic argument first: keep deposits — and the technology — at home Every dollar a customer moves into a third-party stablecoin or fintech app is a deposit that **leaves your balance sheet**. The float, the net interest margin, and increasingly the customer relationship accrue to the issuer or the app — while the institution that did the KYC and bears the regulatory burden becomes a funding source for someone else's business model. PulseVM plus the **Metal Dollar** network inverts that flow: - **Your institution issues the tokenized dollars.** Customers get instant, programmable, 24/7 money — and the deposits backing it **stay on your balance sheet**, earning your margin. - **You own the customer relationship and the data.** The wallet is your app; the account is your named account; the permissions are your policy. - **You own the rails.** The institution (or consortium) operates the network — technology competency compounds inside the institution instead of being rented. - **Interoperate on your terms.** Metal Dollar provides a common settlement asset across the ecosystem — instant institution-to-institution transfer — while each network's rules remain its own. **One line: the same product that stops deposit flight makes you the technology provider instead of the disintermediated party.** ## The primitives already match how you work | Banking concept | PulseVM primitive | |---|---| | Named, KYC'd entities | Named accounts (`acmecu.treas`) | | Authorization matrix | Hierarchical permissions — native | | Dual control / maker-checker | [Weighted multisig](/guide/multisig) on any permission | | Key rotation & recovery | Native `updateauth`; assets never move | | HSM / enclave custody | secp256r1 (R1) keys natively | | Customer pays no gas | Institution stakes resources; users see an app | | "When is it settled?" | Instant, irreversible — [no reorgs by construction](/guide/finality) | | Audit trail | Full indexed history, human-readable actions | Each of these is solvable on EVM — by *additional* infrastructure, frameworks, and audit surface. Here they are the floor. ## Permissioned is the design point, not a compromise Your validators are named institutions under legal agreements. Block producers are elected and replaceable. The network's rules — account policy, fee models, asset-level controls, freeze/clawback under court order — live in **system contracts your organization owns and can modify**, on an execution model with a decade of customization precedent (WAX, Telos, FIO, XPR Network). ## Not bare infrastructure A deployment starts with working products, not a toolkit: the **WebAuth wallet** (passkey-grade custody with named accounts), **Metal X** (a running order-book exchange), a **loan protocol**, and the indexers, explorers, and SDKs that come from operating these networks in production. ## Talk to us The pilot shape we recommend: a consortium runs a small validator network, issues a tokenized test-deposit asset, and moves intra-member settlement on it for 90 days — small, sovereign, measurable. **[Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/institutions/credit-unions.md --- description: "Blockchain for credit unions and leagues — member-to-member settlement, enterprise-grade custody, and deposits that stay at home." --- # For Credit Unions & Leagues The consortium model fits the movement's structure natively: - **A league operates the validator set**; member credit unions are named accounts with their own permission trees. - **Shared branching and member-to-member settlement** become intra-chain transfers — instant, auditable, fee-free at the member level. - **Smaller institutions inherit enterprise-grade custody** — multisig, key rotation, HSM-backed keys — without building any of it. - **Deposits stay home**: league- or CU-issued tokenized dollars on Metal Dollar rails give members modern money movement while the funding stays on member balance sheets. The economics and primitives are the same as the [banks case](/institutions/banks) — the governance shape (league as operator, members as participants) is what makes it especially natural here. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/institutions/enterprises.md --- description: "Consortium blockchain for enterprises — private per-relationship networks for supply chain, settlement and B2B with rules you control." --- # For Enterprises & Consortia Supply-chain provenance, loyalty and rewards, inter-company settlement, B2B invoicing — wherever multiple organizations need a shared, authoritative record with rules they agree on, the per-consortium model fits. - **A network per business relationship.** A consortium operates its own chain with its own validator set; member companies are named accounts with their own permission trees. Data is shared among the members, not the world. - **Rules that match the agreement.** Settlement terms, access policy, asset definitions, and fee models live in system contracts the consortium owns — not hard-coded by a platform vendor. - **Authorization that mirrors your org chart.** Role keys, [weighted multisig](/guide/multisig) for approvals, delegation between subsidiaries and parents — your existing authority structure expressed directly. - **Settlement you can reconcile against.** [Instant, irreversible finality](/guide/finality) and free reads mean every counterparty (and every auditor) sees the same authoritative state with no confirmation-window ambiguity. - **Interoperate by choice.** Networks in the Metal ecosystem share consensus infrastructure and can bridge as the business relationship requires — connection is a decision, never a default exposure. The same primitives that make this work for banks — named accounts, native permissions, deterministic settlement, owner-defined rules — apply directly to any multi-party enterprise process. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/institutions/government.md --- description: "Blockchain for government and governance networks — named entities, irreversible records, sovereign deployment, and free public audit access." --- # For Government & Governance Networks Registries, disbursements, inter-agency settlement, and procurement audit trails want exactly what this environment provides: - **Named entities and delegated authority** — agencies, departments, and officers as accounts and permissions - **Irreversible records** with complete, freely readable audit trails - **Rules set by the deploying authority** — system contracts the operator owns - **Accountable validators** — DPoS's "named, elected, replaceable operators" is how public institutions already work - **Sovereignty** — the network, its data residency, and its rule-set are domestically operated; no dependency on a foreign public chain's governance **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/institutions/objections.md # Objections, Answered We steel-man these because credibility is the product. ## "Enforce permissions sounds like control" Other way around — they are permissions **the account holder sets on their own account**: which of *your* keys can do what. Nothing protocol-level decides who transacts. And the rule-sets themselves are forkable: anyone can deploy their own network with their own validators. Opt-in rule-sets have no central authority to abuse. ## "Small validator sets can collude" In a public-chain context, a real critique. In a consortium of legally-bound, named institutions, the validator set **is** the governance body — the same parties who would govern any shared financial infrastructure, now with cryptographic enforcement and replaceability. ## "Single implementation / vendor risk" Normal for institutional software — mission-critical systems are routinely run on vendor relationships with commercial support. Mitigations here are contractual (support, SLAs, escrow) plus open repositories and a reference implementation (Antelope/Leap) that anchors the semantics independently of any one codebase. ## "Where's the privacy?" The most important privacy lever is one public chains lack: the **network boundary**. On a private subnet the ledger exists only among the member institutions — no public mempool, no public explorer, nothing on the public internet. Finer-grained confidentiality between members is an architecture choice (per-relationship subnets, application-layer encryption). See [Privacy & Confidentiality](/guide/privacy). ## "How mature is this, really?" Two honest parts. **The semantics are a decade old and run in production.** PulseVM implements the Antelope execution model (Leap 5.0.3) that XPR Network runs today, and carries core components — the chainbase state database, the libfc crypto/serialization layer — over directly from the reference implementation. The account model, permissions, and resource economics are not experiments. **Where PulseVM is new, correctness is measurable, not asserted.** The new surfaces are the Rust execution host and the consensus integration. Because a mature reference implementation exists and runs in production, hardening is mechanical: - **Differential testing** replays identical action streams through Leap 5.0.3 and PulseVM and diffs the results — every divergence is a found bug with ground truth attached. - **Ported regression suites** inherit a decade of fixed bugs as executable assertions. Engineering is tracked openly and rigorously — serious counterparties get an **engineering-status register**, not adjectives. The combination of a decade-old execution model and differential testing against a production reference is what lets an institution move from evaluation to deployment with confidence. --- # SOURCE: https://pulsevm.dev/institutions/technical-evaluators.md --- description: "PulseVM for technical evaluators — architecture, integration, operations, security posture and the failure model for a sovereign institutional blockchain." --- # For Technical Evaluators CTO-to-CTO. The value proposition is elsewhere on this site; this page answers the question a technical decision-maker actually asks: *can I operate this, integrate it, and stand behind it?* ## Where it sits in your architecture PulseVM is a settlement and record layer, not a replacement for your systems of record — it sits alongside them. - **Integration surface**: a native JSON-RPC API plus an Antelope-compatible REST layer, so standard tooling (eosjs, @proton/js, indexers) works against it. See the [API reference](/build/api). - **System-of-record bridge**: [Hyperion](https://github.com/MetalBlockchain/pulsevm-hyperion) provides full, queryable history — the natural integration point for reconciliation, reporting, and feeding your existing ledger/GL. Reads are free, so analytics and audit impose no cost or rate pressure. - **Contracts as your business logic**: rules live in [Rust](/build/quickstart-rust), C++, or [TypeScript](/build/quickstart-typescript) contracts you write and own — versioned, reviewed, and deployed on your schedule. ## Operating a network A network is a set of validator nodes (metalgo + the PulseVM plugin) and the system contracts that define its rules. See [Launch Your Own Network](/network/launch). - **Nodes** run on standard Linux hosts under a service manager; a consortium starts with a small, named validator set. - **Observability**: each node reports head and last-irreversible block and standard node metrics — health is a simple, continuous signal. - **Upgrades**: consensus-affecting plugin upgrades roll out across the validator set in coordinated windows — standard BFT-network practice, and a governance event the consortium controls. - **Backup & recovery**: staking keys are backed up out of band; chain state is deterministically reproducible — a node can rebuild its state by replaying the chain, so recovery is resumption, not reconstruction. ## Failure model Finality is a **safety guarantee**: the network never produces two conflicting final states. If the validator set could not reach quorum, the protocol favors safety over liveness — it waits for quorum and resumes rather than forking. For a settlement system this is the correct trade: there is never a reconciliation problem to clean up, only resumption. There are no reorgs to handle and no probabilistic-finality windows to design around. ## Security & correctness posture - **Open source — including the chain's own rules.** The VM ([pulsevm](https://github.com/MetalBlockchain/pulsevm)), the CDTs, and the **system contracts themselves** are public and reviewable: the token, system, multisig, and bios contracts live in [pulse-cdt-rust/contracts](https://github.com/MetalBlockchain/pulse-cdt-rust/tree/master/contracts). The logic that governs accounts, resources, and assets is auditable source, not a closed binary — no black-box trust required. - **Proven execution model.** PulseVM implements the Antelope model (formerly EOSIO) running XPR Network, WAX, and Telos in production, and carries core components — the chainbase state database and the libfc crypto/serialization layer — directly from the reference implementation. The semantics are not new. - **Differential testing against a production reference.** Because a mature reference implementation exists, correctness is *measured*: identical action streams are replayed through the reference and through PulseVM and the results diffed — every divergence is a concrete bug with ground truth attached, rather than a judgment call. The system is hardened through real-world operation, not adjectives. - **Responsible disclosure.** Security concerns can be raised privately — [contact Metallicus](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs). ## Continuity & support PulseVM is built and maintained by **Metallicus**, with commercial support, SLAs, and deployment engineering available — the vendor relationship model institutions already run their core systems on. Because the stack is open source and anchored to a public reference implementation (Antelope/Leap), it is not locked to a single codebase or a single team: the semantics survive independently of any one vendor. ## A sensible evaluation path 1. **Read** the [architecture](/guide/what-is-pulsevm) and [security model](/guide/accounts-permissions). 2. **Prototype** against the [public test network](/network/endpoints) — deploy a contract, exercise the permission and multisig model, integrate a read path via Hyperion. 3. **Pilot** a small sovereign network: a handful of validators, a tokenized test asset, real settlement flow for a defined period — small, isolated, measurable. 4. **Engineering-status register** and deployment runbooks are available to counterparties under NDA. **[Talk to us — Contact Metallicus →](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs)** --- # SOURCE: https://pulsevm.dev/network/endpoints.md # Network Endpoints ## A-Chain Alpine (testnet) | | | |---|---| | RPC (native JSON-RPC) | `https://a-chain-testnet.protonnz.com/ext/bc/6v9NieZiX3e8eQz3CyJMtXB6YzV2RtnxcRyLAmSgFWWk5Qs6y/rpc` | | REST (Antelope-compatible) | `https://a-chain-testnet.protonnz.com/v1/chain/…` | | History (Hyperion) | `https://hyperion.a-chain-testnet.protonnz.com` | | Blockchain ID | `6v9NieZiX3e8eQz3CyJMtXB6YzV2RtnxcRyLAmSgFWWk5Qs6y` | | Chain ID | `0d6f033e887fae475d641104b6e87762b6c869e87a101afeeb64d608ab376618` | | Explorer | A-Chain Testnet on the Metallicus explorer | ::: tip Testnet Alpine is the public test network for A-Chain. Core token is SYS (4 decimals). ::: --- # SOURCE: https://pulsevm.dev/network/launch.md --- description: "Launch your own blockchain — deploy a sovereign PulseVM network on metalgo with your own validators, genesis and system-contract rules." --- # Launch Your Own Network PulseVM is a virtual machine plugin for **metalgo** (Metal Blockchain's node). Standing up your own network — sovereign, with your own validators and your own rules — is a provisioning exercise, not a research project. This is the path that makes PulseVM "your network, your rules" rather than "a chain you join." > For **local development**, the fastest path is [metal-network-runner](https://github.com/MetalBlockchain/metal-network-runner), which spins up a throwaway multi-node network on your machine. The steps below describe a real, persistent deployment. ## The pieces | Component | Role | |---|---| | **metalgo** | the node software; runs consensus (Avalanche Snowman) and hosts VMs | | **PulseVM plugin** | the VM binary, placed in metalgo's `plugins/` directory, keyed by its **VM ID** | | **Subnet** | the set of validators that runs your chain | | **Genesis** | initial chain state — core token, the bootstrap account, parameters | | **System contracts** | the rules of your chain (accounts, resources, token), deployed from [pulse-cdt-rust](https://github.com/MetalBlockchain/pulse-cdt-rust) | ## Shape of a deployment 1. **Provision hosts** — one Linux box per validator (start with a handful for a consortium). 2. **Install metalgo** on each, and place the **PulseVM plugin** binary in the plugins directory under its VM ID. Build the plugin from [MetalBlockchain/pulsevm](https://github.com/MetalBlockchain/pulsevm) or use a release artifact. 3. **Create the subnet** and add each node's NodeID as a validator. The subnet owner controls validator membership — this is your governance boundary. 4. **Define genesis**: the core/system token, the bootstrap (system) account and its keys, and chain parameters. This is where you set the economics and identity of your network. 5. **Bootstrap the chain**: deploy the system contracts (token, system, governance) to the system account, set up the initial permission structure, and activate any protocol features your deployment needs. 6. **Operate**: nodes run under a service manager (e.g. systemd); monitor head and last-irreversible block; coordinate plugin upgrades across the validator set. ## Customizing the rules Because the chain's behavior lives in **system contracts you control**, this is also where customization happens — account-creation policy (e.g. KYC-gated onboarding), fee models, asset-level controls (freeze/clawback under legal order), resource economics, and settlement parameters. The Antelope lineage has a decade of precedent for forking the system layer into different economies (XPR Network, WAX, Telos, FIO each did exactly this). ## Operating notes - Coordinate plugin upgrades across the validator set rather than node-by-node — consensus-affecting changes should roll out in a planned window. - Back up each node's staking keys before any maintenance. - Detailed runbooks, provisioning scripts, and monitoring exist from operating live networks — [contact Metallicus](https://metallicus.com/contact-us?utm_source=pulsevm.dev&utm_medium=docs) for deployment support, or ask in the community channels. ## Why run your own A network you operate keeps the data, the rules, the validator set, and the upgrade schedule under your control — and, with institution-issued assets on it, keeps the deposits and the customer relationship on your balance sheet. See [For Banks & Fintechs](/institutions/banks). --- # SOURCE: https://pulsevm.dev/network/validator.md # Run a Validator A PulseVM network validator is a metalgo node with the PulseVM plugin, registered to the subnet. ## Shape of the work 1. **Provision** a Linux host (amd64), install metalgo, place the PulseVM plugin binary in the plugins directory. 2. **Generate node identity** (NodeID) and back up the staking keys. 3. **Track the subnet** in node config; sync the chain. 4. **Register**: the subnet owner adds your NodeID as a validator (consortium governance decides who validates). 5. **Operate**: run metalgo under a service manager; monitor head and last-irreversible block; roll plugin upgrades across the validator set in coordinated windows. ::: tip Coordinate upgrades Consensus-affecting plugin upgrades should roll out across the validator set in a planned window rather than node-by-node — standard practice for any BFT network. ::: Detailed runbooks (provisioning scripts, upgrade/rollback tooling, monitoring) exist from operating the Alpine fleet — ask in the community channels. --- # SOURCE: https://pulsevm.dev/resources.md # Repositories & Resources The canonical home for PulseVM and the Metal Blockchain stack is **[github.com/MetalBlockchain](https://github.com/MetalBlockchain)**. ## PulseVM core | Repo | What it is | |---|---| | [pulsevm](https://github.com/MetalBlockchain/pulsevm) | The virtual machine itself — "fast virtual machine focused on banking" | | [metalgo](https://github.com/MetalBlockchain/metalgo) | The Metal Blockchain node PulseVM plugs into | | [leap](https://github.com/MetalBlockchain/leap) | C++ Antelope reference implementation — the semantic anchor | ## Contract development | Repo | What it is | |---|---| | [pulse-cdt](https://github.com/MetalBlockchain/pulse-cdt) | C++ Contract Development Kit | | [pulse-cdt-rust](https://github.com/MetalBlockchain/pulse-cdt-rust) | Rust CDT — and the chain's **open, auditable system contracts** ([`contracts/`](https://github.com/MetalBlockchain/pulse-cdt-rust/tree/master/contracts): system, token, msig, bios) | | [pulse-tsc](https://github.com/paulgnz/pulse-tsc) | TypeScript/AssemblyScript contracts (community) | ## SDKs & tooling | Repo | What it is | |---|---| | [pulsevm-js](https://github.com/MetalBlockchain/pulsevm-js) | TypeScript SDK — signing, ABIs, transact | | [pulse-cli-ts](https://github.com/paulgnz/pulse-cli-ts) | Working CLI for accounts, contracts, actions, permissions (community) | | [pulsevm-hyperion](https://github.com/MetalBlockchain/pulsevm-hyperion) | Full-history API / indexer for PulseVM chains | | [metal-network-runner](https://github.com/MetalBlockchain/metal-network-runner) | Run a local Metal network for development | | [metal-monitoring](https://github.com/MetalBlockchain/metal-monitoring) | Node monitoring tooling | ## Ecosystem | Repo | What it is | |---|---| | [explorer](https://github.com/MetalBlockchain/explorer) | Metal Blockchain explorer | | [metal-wallet](https://github.com/MetalBlockchain/metal-wallet) | Web wallet | | [metal-docs](https://github.com/MetalBlockchain/metal-docs) | Metal Blockchain documentation | ## This site [paulgnz/pulsevm-docs](https://github.com/paulgnz/pulsevm-docs) — corrections and PRs welcome. --- # SOURCE: https://pulsevm.dev/wallets.md # Wallets Two wallets for PulseVM networks — pick the one that fits your platform and custody needs. ## WebAuth Metallicus's flagship wallet for XPR Network / PulseVM — **mobile (iOS/Android) and browser**. Passkey/WebAuthn custody, in-app swap, staking, and dapp connect. Best for everyday users. - **Get it:** [webauth.com](https://webauth.com) ## PulseVM Wallet (macOS) A native **macOS desktop** wallet for institution-grade, **hardware-backed** custody: - **Secure Enclave** keys (biometric, non-exportable) and **YubiKey (PIV)** hardware keys. - **Decode-before-sign** — every transaction is shown as real actions before you approve. - **Multisig**, key & permission management (`updateauth`, link keys), network manager. - **Dapp connect** over `pulsevm://` with a seamless relay (no second browser tab). ⬇ Download for macOS (.dmg) - **Download:** [GitHub Releases](https://github.com/paulgnz/pulse-wallet/releases/latest) — signed + notarized; open the `.dmg`, drag **PulseVM** to Applications. - **Source:** [github.com/paulgnz/pulse-wallet](https://github.com/paulgnz/pulse-wallet) (open source, MIT). - **Connect a dapp:** see [Connect Wallet (Web SDK)](/build/connect-wallet) and the live demo. > Currently a beta on the A‑Chain testnet. ## Build a dapp that connects to these wallets See **[Connect Wallet (Pulse Web SDK)](/build/connect-wallet)** for the `ConnectWallet()` API and two SDKs (lightweight desktop connector + full proton-web-sdk Pulse Edition).