← CreditChain

Developers

CreditChain's own website (OUTERNET) is just one client of a plain HTTP + JSON API - the same one you can build against. No API key, no signup: reads are open, and writes are authorized by a signature from the wallet keypair itself (see "Authenticating writes" below).

GET /network

(response will appear here)

Base URL

Every endpoint below is relative to the node's own base URL - same host as this website, port 8080 (this website's static files are served separately, from a different port, purely for local development convenience). In production that's https://creditchain.site:8080 (or wherever the node you're talking to is actually hosted, if you're running your own - see "Run your own node/testnet" below).

Connecting to Testnet vs Mainnet

Testnet and Mainnet are two completely independent CreditChain networks - separate chains, separate genesis, separate validator pools, separate everything - reachable through the exact same protocol on two different ports of the same host. There's no separate API shape for either: build against the Base URL above, and point it at whichever network's port you want.

• Testnet - https://creditchain.site:8080 - no real value, freely reset-able.
• Mainnet - https://creditchain.site:9090 - real value, not yet professionally audited (see the site-wide banner). Each account's total BTC + ETH holdings are capped during this stabilization period.

CORS is wide open (Access-Control-Allow-Origin: *) on both, same as every other endpoint documented here - a third-party wallet or app can call either network directly with no special allowlisting. The OUTERNET website itself switches between the two the same way: the network picker in the top banner just changes which port its own requests go to and reloads - there's no hidden coordination between the two chains, they're genuinely separate.

Reading data (no auth needed)

Every GET endpoint is a plain, unauthenticated public read - wallet balances, the block explorer, governance proposals, hub rates, everything. Example:

curl "/wallet?address=YOUR_ADDRESS_HEX"

Authenticating writes

Every mutating (POST) endpoint requires a signed envelope proving you actually hold the wallet's private key - the same Ed25519 signing the browser wallet itself uses via crypto.subtle (Web Crypto), no third-party crypto library needed. An address is just SHA256(publicKey)[:20], so the server never needs to pre-register your key - each signed request proves itself.

{
  "address": "<your 40-hex-char address>",
  "publicKey": "<hex-encoded Ed25519 public key>",
  "timestamp": 1234567890,
  "payload": { /* endpoint-specific fields */ },
  "signature": "<hex - Ed25519 signature over address|publicKey|timestamp|compact-JSON(payload)>"
}

Timestamps outside a ±60s window are rejected (replay protection), and an exact signature can't be replayed twice. See website/js/api.js's apiPostSigned in this project's own source for a complete, working reference implementation you can port to any language with Ed25519 support.

Endpoint reference

Grouped by area - GET unless marked (POST, signed). This isn't every field of every request/response; read the linked source file for exact shapes.

Price-reference pools (ETHTEST / BTCTEST)

Two developer-only, CCT-paired AMM pools exist purely as real, on-chain price-discovery references - ETHTEST and BTCTEST. Both use the exact same core.LiquidityPool constant-product mechanics every custom-token pool uses, and both are fully reachable through the ordinary public endpoints (/pool?symbol=ETHTEST, /token/balance?symbol=BTCTEST&address=..., the existing swap/add-liquidity handlers, GET /pool/price-history?symbol=BTCTEST). CreditChain itself does not surface a direct trading UI for these two - no nav link, no swap page entry - so if you want to seed liquidity or trade against them, do it directly against the API, same as any other pool endpoint. They exist so governance's PREDICTION proposal kind (see api/prediction_vote.go) has a real, tamper-resistant price to resolve against, not a UI feature of their own.

Mainnet Mechanics

A real explainer of the mechanics already live on both networks today - not a marketing roadmap. Reachable from its own "Mainnet Mechanics" link in the main site's navbar, separate from "Whitepaper" (which now points to the actual whitepaper PDF on mainnet, and to the testnet-specific whitepaper.html page on testnet).

Run your own node - or your own entire testnet

Yes - a node is a separate, ordinary process (creditchaind) with its own DATA_DIR. Run one with no PEERS set and you have your own fully isolated private testnet from block zero, completely separate from the public CreditChain network - useful for local development or a private staging environment. Run several nodes pointed at each other (PEERS + a shared NETWORK_SECRET you choose yourself) and you have your own private multi-node network. This network is currently permissioned (not open/permissionless) - joining someone else's live network (including the public CreditChain one) requires that operator to hand you their NETWORK_SECRET and add your node to their PEERS list; there's no self-serve join flow yet.

git clone https://github.com/Danielcruse/creditchaind.git
cd creditchaind
go build -o creditchaind .

DATA_DIR=./data PORT=8080 ./creditchaind
# no PEERS set - this is now its own standalone chain, genesis block already produced

Full environment variable reference, Docker Compose setup, and how to verify two nodes have actually converged: see ops/NODE_OPERATOR.md in the project source.

Disclosures

• This is a testnet. CCT/ETHTEST/USDCTEST/REPT have no real monetary value.
• Not yet professionally audited - see the whitepaper for the full disclosed-gaps list.
• The public network is permissioned - see "Run your own node" above.