Exchange Integration

Tidecoin exchange integration is mostly a Bitcoin Core integration with three Tidecoin-specific responsibilities: validate Tidecoin address networks exactly, size withdrawals for post-quantum signatures, and understand the AuxPoW activation gate before enabling post-AuxPoW output types on mainnet.

This page is the exchange operations checklist. It is not the command schema; use RPC Reference for command arguments and RPC Integration Patterns for reusable polling, retry, and reorg patterns.

Listing readiness checklist

Before deposits are opened, an exchange integration should have:

Area	Requirement
Node fleet	At least two independently monitored Tidecoin Core nodes.
Network checks	Explicit mainnet/testnet/regtest address validation.
Deposit ingestion	A reorg-aware cursor based on block hash, not only height.
Withdrawal sizing	Fee estimates based on Tidecoin transaction vbytes, not Bitcoin-sized assumptions.
Wallet policy	A documented hot-wallet scheme policy and cold-storage seed procedure.
Broadcast safety	`testmempoolaccept` before `sendrawtransaction` for externally built withdrawals.
Incident gates	Automatic deposit/withdrawal pauses during IBD, peer loss, reindex, deep reorgs, or wallet failures.
Test coverage	Regtest or testnet coverage for deposit credit, reorg removal, withdrawal broadcast, and address rejection.

Node layout

Run public-facing services and wallet-signing services as separate roles. Explorer or deposit indexers can use read-only node RPC credentials. Hot-wallet automation should use a wallet-scoped RPC credential and should not share a node with untrusted public API traffic.

Role	Purpose	Notes
Primary deposit node	Tracks blocks and wallet notifications.	Keep fully synced; do not credit deposits while in IBD.
Secondary verification node	Cross-checks best block hash, height, and mempool behavior.	Use for alerting and manual failover.
Wallet node	Creates and signs withdrawals.	Bind RPC to localhost or a private network only.
Indexer node	Optional block/transaction scan backend.	Use if the exchange does not rely only on wallet RPC.

Address policy

Do not infer Tidecoin network from string length or from a Bitcoin address library configured with default Bitcoin constants. Use the Tidecoin version bytes and HRPs listed in Address Validation.

Mainnet exchange policy should normally:

Accept only mainnet address encodings for mainnet deposits.
Reject testnet and regtest HRPs and Base58 prefixes at the API boundary.
Support current mainnet receive types that the exchange has tested end to end.
Decode PQ witness v1 addresses, but avoid enabling them for mainnet deposits while mainnet AuxPoW remains disabled.

Testnet and regtest integrations should include PQ witness v1 coverage because those networks activate the post-AuxPoW ruleset earlier.

Deposit monitoring

Wallet-backed deposit systems can use listsinceblock as the main cursor. Store the returned lastblock hash and use it on the next poll.


tidecoin-cli -rpcwallet="deposits" listsinceblock "<lastblock>" 6 true true

Important behavior:

Field or argument	Integration meaning
`blockhash`	Cursor from the previous `lastblock`.
`target_confirmations`	Controls the returned `lastblock`; it is not a transaction filter.
`transactions`	Wallet transactions to evaluate for crediting.
`removed`	Transactions removed by a reorg when `include_removed` is true.
`lastblock`	Persist this as the next cursor after processing the response.

If the exchange runs a custom indexer instead of a wallet-owned deposit wallet, scan blocks by hash using getblock <hash> 2, persist height, hash, and previousblockhash, and rewind to the common ancestor when the stored parent no longer matches the active chain.

Do not credit deposits from a single unconfirmed mempool observation. Mempool tracking is useful for UX and fraud monitoring, but final account credit should come from confirmed block processing and the exchange’s confirmation policy.

Confirmation policy

There is no universal confirmation count that can be correct for every exchange, amount, and liquidity profile. A practical initial policy is:

Deposit type	Starting policy
Small normal deposits	6 or more confirmations.
Large deposits	More confirmations and manual risk controls.
Mined funds	Wait for coinbase maturity before treating funds as spendable.
Reorg recovery	Debit or freeze credits for transactions returned in `removed`.

The final policy belongs to the exchange’s risk model. Document the threshold in the listing runbook and make sure the implementation can change it without a code deployment.

Withdrawal flow

Withdrawal construction can use Tidecoin Core wallet RPC or an offline PSBT flow. For hot-wallet withdrawals before mainnet AuxPoW activation, use Falcon-512 policy unless the active network explicitly allows another scheme.

Minimum withdrawal pipeline:

Validate the destination address against the selected network.
Build the transaction with wallet RPC or an offline PSBT flow.
Estimate final vbytes using Tidecoin’s PQ signature sizes.
Run testmempoolaccept on the final hex.
Broadcast with sendrawtransaction.
Track the transaction by txid, block inclusion, and reorg state.

Common broadcast failures are usually policy, fee, dust, or consensus-rule errors. See Errors for how to handle RPC error categories and Transaction Size & Fees for Tidecoin-specific fee sizing.

Hot and cold wallet policy

Tidecoin wallets use PQHD seed management for post-quantum key material. Treat PQHD master seeds as high-value signing material. A hot wallet should hold only operational liquidity; reserves should be controlled by offline or tightly restricted cold procedures.

Operational points:

Topic	Guidance
Hot wallet	Keep enough liquidity for normal withdrawals, then rebalance from cold storage.
Cold wallet	Use offline signing or tightly controlled wallet hosts.
Seed inventory	Track PQHD seed IDs and backup status.
Scheme policy	Record the selected receive and change scheme policy per wallet.
PSBT metadata	Preserve PQHD origin metadata through offline signing workflows when used.

Useful wallet commands include listpqhdseeds, importpqhdseed, setpqhdseed, removepqhdseed, and setpqhdpolicy. See RPC Reference for command details.

Pause conditions

Automated deposit or withdrawal processing should pause when:

Condition	Why it matters
Node is in initial block download	The local chain view is not reliable.
Peer count is below the exchange threshold	The node may be isolated.
Best block differs across exchange nodes	The fleet may be split or lagging.
A reorg exceeds the exchange threshold	Previously credited deposits may need review.
Wallet RPC is locked or unavailable	Withdrawal signing cannot be trusted to complete.
Address parser rejects a network or output type unexpectedly	A deployment may have wrong chain constants.

Source of truth

Topic	Canonical page
Address prefixes and HRPs	Address Validation
Fee sizing and PQ transaction weights	Transaction Size & Fees
RPC polling and reorg handling	RPC Integration Patterns
RPC command schemas	RPC Reference
RPC deployment security	RPC Security
AuxPoW activation state	Activation Status