Bloch IncOPSBloch Inc ↗

03 / WALLET + EXCHANGE OPERATIONS

Sign locally.
Reconcile precisely.

The published Genesis-4 JavaScript SDK creates or restores a wallet locally, builds signed transfers and queries complete receipts. A node never receives a mnemonic or creates an address.

Create locally ↓Build a transfer ↓
IMPLEMENTATION STATUS
01Local wallet creationPUBLISHED / NODE.JS SDK
02JavaScript signing SDKPUBLISHED / SOURCE PACKAGE
03Canonical receipt APIPUBLISHED / INCLUDED TRANSACTIONS
04Hosted key serviceNOT OFFERED
Security boundary

Generate and back up wallet keys in a trusted client or signer. This site has no mnemonic field, key store, transaction signer or broadcast button.

01 / LOCAL WALLET CREATION

Generate the keys
where you control them.

The Genesis-4 SDK now exposes createLocalWallet() and deriveLocalAddress(). They use the pinned wallet core inside your Node.js process and do not call an RPC or remote API.

FRESH MAINNET IDENTITY
import { createLocalWallet } from '@blochprotocol/genesis4-sdk';

const wallet = createLocalWallet();
// wallet.address is a checksummed mainnet address.
// Back up wallet.mnemonic in your controlled key ceremony.
console.log(wallet.address);

The function returns a 24-word mnemonic once to the caller. The SDK does not persist or encrypt it; do not log it or send it to a website.

RESTORE / VERIFY ADDRESS
import { deriveLocalAddress } from '@blochprotocol/genesis4-sdk';

const recovered = deriveLocalAddress({ mnemonic });
if (recovered.address !== expectedAddress) {
  throw new Error('Address mismatch');
}

Restoration returns an address without transmitting the phrase. For an interactive encrypted wallet, use Postern Wallet. Older identities may need their original derivation convention.

Local generation is not hosted custody.

There is no mnemonic form or key store on Bloch Ops. Protect the calling process, backup ceremony and resulting wallet according to your own custody policy.

02 / HIGH-LEVEL TRANSACTION INTERFACE

Four inputs.
Signed bytes out.

createSignedTransaction handles UTXO selection, the current fee and epoch, construction, signing and serialization through the pinned Genesis-4 wallet core. Amounts are decimal strings.

INSTALL / NODE.JS 20+
npm install https://ops-blochinc.xyz/wallets/downloads/blochprotocol-genesis4-sdk-0.1.13.tgz

The package is source-distributed and versioned. Check its code and pinned WASM hash before processing value.

Download SDK package ↗ Verify SHA-256 ↗
SIGN / LOCAL PROCESS
import { createSignedTransaction } from '@blochprotocol/genesis4-sdk';

const signed = await createSignedTransaction({
  addressFrom: process.env.BLOCH_ADDRESS_FROM,
  mnemonic: process.env.BLOCH_MNEMONIC,
  addressTo: process.env.BLOCH_ADDRESS_TO,
  amount: '1.25000000',
  rpcUrl: process.env.BLOCH_RPC_URL,
});

console.log(signed.txid, signed.rawHex);

rawHex is the complete signed serialized transaction for sendrawtransaction([rawHex]). Store the complete signed object, including txid, rawHex, signingRootHex and rawHash, before sending. The SDK checks these fields and the node’s byte hash on broadcast.

Broadcast is a separate decision.

Use an exchange-controlled Genesis-4 node or an authenticated write endpoint. The public gateway may be read-only. Optional cursor-based UTXO enumeration in SDK 0.1.13 requires a node release that supports it; current mainnet uses the legacy mode. A timeout does not prove failure. Use trackSignedTransaction(signed) to check the stored txid without rebuilding or rebroadcasting; retry only the same bytes if your policy calls for it.

03 / TRANSACTION RECEIPT

A txid becomes an
operational record.

The archival API joins an included transaction with a fresh chain-head observation. It returns inputs, outputs, satoshi amounts, height, slot, confirmations and finality fields.

HTTP GET / PUBLIC
GET https://blochl1.com/api/v1/transactions/{txid}

Example included transaction:

Open live JSON receipt ↗

Download transaction query OpenAPI contract ↧

SDK / NODE.JS
import { getTransaction } from '@blochprotocol/genesis4-sdk';

const tx = await getTransaction(txid);
console.log({
  inputs: tx.inputs,
  outputs: tx.outputs,
  height: tx.height,
  slot: tx.slot,
  confirmations: tx.confirmations,
  finalized: tx.finalized,
});
READ-ONLY RECEIPT INSPECTOR

Check a transaction on mainnet

Enter a 64-character txid. This page reads the public archival API, compares repeat lookups of the same txid in this tab, and checks node status if no included receipt exists. Optionally compare outputs against a mainnet deposit address or public script hash and integer satoshi amount in this browser. Download a JSON record of a validated included receipt, the local comparison and optional output match. The file is public-data evidence for your own reconciliation policy, not a credit authorization. This page does not submit transactions or store lookup history after the tab closes.

Enter both fields to compare outputs locally. A checksummed mainnet address is verified and converted to its script hash in your browser; a raw 64-hex hash has no checksum. Only the transaction ID is sent to the public APIs; never enter a mnemonic or key.

01 / MATCH

Use inspectDepositOutputs() to match the expected address script hash, list each outpoint and sum integer value_sat strings.

02 / INCLUDE

Record txid, block ID, height, slot and transaction index. Recheck the block ID if the chain reorganizes.

03 / FINALIZE

Credit only against your explicit confirmation and corroborated finality policy. Mempool acceptance is not a receipt.

The SDK provides getDepositTransaction({txid, addressTo, amount}) for one-call receipt lookup and exact output matching. Expected amounts must be positive, and an exact match requires at least one matching output. It also provides inspectDepositOutputs() for an already saved receipt, plus getTransactionObservation() and compareTransactionObservations() for unresolved or changed receipts. These are measurements, not credit decisions. Pause crediting if the index or corroborated chain head is unavailable.

Download offline evidence verifier ↧ · SHA-256 ↧ · Usage and limits ↗. The verifier recalculates local claims from the saved public receipts; it does not authenticate the indexer or authorize credit.

04 / HOSTED SERVICE BOUNDARY

Keep secrets where
the owner controls them.

Genesis-4 nodes explicitly reject getnewaddress because they hold no wallet. Local SDK creation is available; a hosted endpoint that accepts a mnemonic would change the custody and security model.

01

Client-side identity

Create or restore locally with the SDK, Postern Wallet or an integrator-controlled signer. Never submit a seed phrase to a web form or RPC.

02

Public-data APIs

Read chain identity, UTXOs, fees and transaction status from a node. Bind signing to the verified Genesis-4 network.

03

Future Ops interface

Versioned address validation, unsigned preparation and signer adapters are roadmap work. They do not include server-held keys.

Open Postern Wallet ↗Developer portal ↗RPC method catalog ↗