Exchange integration
Summary
Section titled “Summary”This section is for centralized exchanges, swap services, wallets, explorers, payment processors, and other infrastructure providers that want to integrate BitcoinII (BC2).
The goal is to create a clear integration package that reduces back-and-forth and helps service providers quickly find the technical information they need.
This section is still a framework. It should not be sent as final exchange documentation until release verification, confirmation policy, technical contact process, current service status, and RPC examples are reviewed.
Current pages
Section titled “Current pages”BC2 integration package
Section titled “BC2 integration package”- Exchange integration package
- Exchange operator guide
- Deposit monitoring
- Service integration checklist
Listing readiness and exchange research
Section titled “Listing readiness and exchange research”- Native coin exchange listing guide
- Exchange listing target matrix
- Exchange readiness checklist
- Exchange listing packet template
- Why native coins get rejected by exchanges
Source-backed anchors
Section titled “Source-backed anchors”- Network specifications
- Consensus overview
- RPC overview
- RPC configuration
- Node configuration
- Source atlas: blockchain RPC
- Source atlas: raw transaction RPC
- Source atlas: mempool and transaction broadcast RPC
- Source atlas: wallet RPC
- Confirmations
- Reorganizations
Draft checklist
Section titled “Draft checklist”- Project name: BitcoinII.
- Ticker: BC2.
- Official website.
- Official repositories.
- Current wallet release.
- Source code.
- License.
- Network parameters.
- Block explorer links.
- RPC documentation.
- Deposit confirmation recommendation.
- Withdrawal confirmation recommendation.
- Daemon setup notes.
- Wallet backup notes.
- Branding assets.
- Technical contact process.
- Known exchanges and services.
- Integration test procedure.
- Treat BC2 as a native coin, not a token, unless official sources say otherwise.
- Do not recommend confirmation counts until a policy is source-backed or clearly labeled as a draft risk model.
- Do not list a service as active without direct current checking.
- Do not present untested RPC commands as production instructions.
- Clearly separate read-only RPC commands from wallet-moving, broadcast, import/export, private-key, and passphrase commands.
- Do not recommend exposing RPC publicly.
- Keep release-verification status visible.
- Keep technical-contact status visible until confirmed from official or maintainer sources.
- Treat third-party listing-fee estimates as unconfirmed unless the exchange publishes the fee directly.
Related pages
Section titled “Related pages”- Known unknowns
- Open questions backlog
- Documentation coverage
- Documentation polish plan
- Ecosystem index
Verification
Section titled “Verification”Status: Draft Primary sources checked: Partially Notes: This section has source-backed anchors and first-pass exchange listing research, but it remains a framework. Release verification, confirmation policy, contact process, direct ecosystem checks, and tested RPC examples are still required before final service-provider use.