Skip to content

Blockchain Core 0.17.2 / Getting Started

Blockchain Core administrator and privacy guide

Configure networks, wallet privacy, transaction journals, trusted contracts, and callable schemas.

Understand Core's role

Blockchain Core is the free provider-neutral foundation. It defines wallet sessions, networks, proofs, trusted contracts, transaction intents, previews, confirmations, and lifecycle facts. Provider packages such as MetaMask own wallet-specific code. Blockchain Tools owns advanced reads and guarded sending. Core contains no transaction executor and never silently reconnects a wallet on a fresh page.

Networks and wallet privacy

Open Blockchain → Networks to enable only supported targets. Public browser manifests contain identifiers and safe metadata, never private RPC credentials. Open Wallet & Privacy to decide whether connected-wallet information may be associated with a WordPress user.

The redacted transaction journal is disabled by default. Enabling site availability is not consent: each signed-in user must separately grant the current journal policy. Records are capped at 25 per user and expire after seven days. They contain intent/action, ecosystem, CAIP-2 chain, transaction hash/signature, lifecycle status, and server timestamps—not wallet/recipient addresses, amounts, calldata, proofs, provider credentials, or RPC URLs. Users may clear or revoke even after site storage is disabled.

Trusted contracts and callable schemas

Use Blockchain → Trusted Contracts only for reviewed chain/address pairs. Record narrow read/write method allowlists, HTTPS provenance, capability, and risk. Administrator approval means site approval, not independent verification. Installed-code records are read-only.

A callable schema binds one trusted contract method to ordered typed inputs and outputs. It stores no ABI, calldata, values, endpoint, or credential. A schema does not authorize execution: writes still require the exact capability, adapter, simulation, immutable intent, explicit confirmation, idempotency, and wallet prompt.

Troubleshooting and safety

  • No wallet: install and activate a provider package; Core does not bundle one.
  • Network unavailable: enable the target and ensure the provider supports its ecosystem/chain.
  • Journal does not save: verify site availability, signed-in ownership, REST nonce, and current user consent.
  • Contract validation fails: compare exact registry ID, CAIP-2 chain, canonical address, method signature, mode, and capability.
  • Wallet appears without interaction: update Core and provider packages; fresh documents must wait for an explicit visitor action.

Before production writes, test on the correct testnet and verify the complete preview, rejection, cancellation, expiry, account-change, chain-change, receipt, and replacement lifecycle.

Was this documentation helpful?Your response helps us improve this page.