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 the network's owners can change. The core account and authorization rules (how permissions, links and signatures are checked) are native to the VM and cannot be altered by a contract. They are open-source Rust, written with 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
These are the built-in contracts. Your own application contracts (tokens, DeFi, business logic) are separate — see the Rust, C++, and 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 and 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 an Antelope-style producer record (validator admission itself happens on the Metal P-Chain or your validator-manager contract) |
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 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 and permission management
The bootstrap/authority contract. Its actions manage the account permission model directly — these are the operations behind 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) | Bind a permission to one contract action. A key on myacct@trader linked to vault::trade can call that and nothing else: no transfer, no updateauth. See recipes |
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: weighted multisig, key rotation (updateauth — assets never move), delegation, and per-action authorization (linkauth).
Customizing the rules
Because these are contracts, 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). The Antelope lineage has a decade of precedent for forking the system layer. See Launch Your Own Network.