Exchange integration

Mapping common wallet RPC calls

LapseCoin nodes expose an HTTP API, not a JSON-RPC wallet. This table maps familiar Bitcoin Core calls to the closest equivalent. There is no account or label system. Details are on the API and Transactions pages.

Bitcoin Core call	LapseCoin equivalent	Differences
`getnewaddress`	Generate a FALCON-512 keypair yourself and derive the address	No node call. An address is derived purely from the public key, so no node is needed to create one.
`getbalance`	`GET /api/address/{addr}/balance`	Returns `balance_ticks` and `balance_lapse` from chain state
`listtransactions`, `getreceivedbyaddress`	`GET /api/address/{addr}/history`	Flat array with a `direction` of `sent` or `received`. Confirmed transactions only. Sum the outputs yourself.
`sendtoaddress`	Sign locally, then `POST /api/tx/send`	No RPC password. The transaction must be fully signed and carry a correct nonce.
`gettransaction`	`GET /api/tx/{hash}`	Includes `confirmations` (0 means in the mempool)
`validateaddress`	`GET /api/address/{addr}/valid`	Format check only
`estimatesmartfee`	`GET /api/fees`	Returns `next_block`, `min`, `median`, `max` in ticks per byte
`getmempoolinfo`	`GET /api/mempool`	Size and a summary of each pending transaction
`getblockcount`, `getblock`	`GET /api/info` (`height`), `GET /api/block/{height}`	Blocks are addressed by height

Key differences

Integer ticks: 1 LAPSE = 100,000,000 ticks, the same precision as BTC and satoshis. Keep all amounts as integers.
Addresses: twelve dot-separated BIP39 words. Creating one costs nothing, so you can give each customer a unique deposit address instead of relying on memos.
Memo: transactions can carry an optional plaintext memo of up to 200 bytes, visible to everyone forever. It can serve as a deposit tag, but senders may omit it, so a unique address per customer is more robust.
Signatures: FALCON-512 (quantum-resistant), not ECDSA or Ed25519. Use liboqs.
Nonces: strictly sequential per sender, starting at 1. Read the last used nonce from GET /api/state?addr=; it counts pending transactions too, and the next one is that plus one.
Fees: chosen by the sender and priced per byte. Block time targets about 120 seconds, and blocks are capped at 2 MB.
Output limits: up to 500 outputs per transaction, and a sender cannot pay its own address.
No CORS and rate limits: call the API from your backend, and expect per-IP limits on public nodes. Run your own node for production use.

Implementation checklist

Run your own node so your integration does not depend on a third-party API.
Generate deposit addresses from keypairs you control and store the secret keys securely.
Poll /api/address/{addr}/history for received entries, deduplicate by tx_hash, and sum all outputs to your address.
Check /api/tx/{hash} for confirmations and choose a confirmation depth before crediting. Chain reorganizations are possible as in any longest-chain system.
For withdrawals: derive the next nonce, pick a fee using /api/fees, sign with FALCON-512, and POST to /api/tx/send. Serialize withdrawals per sending address so nonces do not collide.
Check the ok field of the broadcast response, and confirm the transaction later by hash.

Cold storage

Because addresses are derived from public keys and /api/tx/send only accepts fully signed transactions, signing can happen entirely offline.

Keep secret keys on an offline machine.
Carry the nonce and fee you determined online to the offline signer, sign the transaction there, and transfer the signed JSON back.
Broadcast from the online machine. The broadcast endpoint needs no authentication.

To back up a key as a recovery phrase instead of a key file, see Wallet integration.