Quickstart

Read the chain in one command.
No key, no account, no SDK.

The public relay at rpc.futurechain.eu serves the read endpoints unauthenticated. Every example below was run against the live network and shows its real response. Writing requires an enrolment token — that part is covered further down, honestly, including what is not ready yet.

Read

Works right now

Paste any of these into a terminal. No headers, no token.

Chain tip

GET /info

curl -s https://rpc.futurechain.eu/info

{
  "chain_height": 1127261,
  "latest_block_height": 1127260,
  "latest_block_hash": "0a1214e858dfcca645951aeba6f7da88…",
  "iso20022_support": "PACS.008.001.13",
  "pending_transactions": 0
}

Balance of an address

GET /balance/{address}

curl -s https://rpc.futurechain.eu/balance/fc_VHLPNqo7dqq2yU32ot2LWSmDRhp3KZRyar

{
  "address":     "fc_VHLPNqo7dqq2yU32ot2LWSmDRhp3KZRyar",
  "balance":     58082028117840,   // satoshis — the integer you compute with
  "balance_ftc": 580820.2811784,   // FTC — for display only
  "utxo_count":  15791
}

Spendable outputs

GET /get_utxos/{address}

curl -s https://rpc.futurechain.eu/get_utxos/fc_VHLPNqo7dqq2yU32ot2LWSmDRhp3KZRyar

[
  {
    "tx_id":        "194fdde82a76af848634899039897ea045c4eb3b…",
    "output_index": 0,
    "address":      "fc_VHLPNqo7dqq2yU32ot2LWSmDRhp3KZRyar",
    "amount":       1000000,        // satoshis = 0.01 FTC
    "block_height": 823147
  }
]

An address with many outputs returns a large array — the one above has 15,791 entries. Page or filter client-side rather than holding it all in memory.

Read this

Three things that will cost you an afternoon

Each of these was hit during development. They are surprising precisely because nothing errors — you get a plausible answer that is wrong.

Errors arrive as HTTP 200

The node returns 200 OK with the failure in the body. A wrong wallet password comes back as 200 plus {"error":"Authentication failed: Invalid password"}.

Check the body, not the status code. A client that branches only on res.ok will treat every failure as a success.

The public relay only keeps recent history

It runs as a light hub with roughly a seven-day block window, so /transaction/{id} answers {"error":"Transaction not found"} for anything older — even though the transaction exists on the chain and the explorer will show it.

The window is a rolling 7 days, so any block height quoted here would be wrong within a week — check against the current tip rather than a fixed number. Use the explorer for history, and the relay for recent activity.

Amounts are satoshis, not FTC

1 FTC = 100,000,000 satoshis. The amount field on a UTXO and the balance field are integers in satoshis; balance_ftc is a convenience float for display.

Never do arithmetic on the float. Compute in integers and convert only when rendering — a rounding error here is a payment error.

Write

Submitting a payment

Writes are authenticated and rate-limited at the edge. A submission carries a full PACS.008 message and is screened for compliance before it can enter a block — if screening cannot answer, the payment does not settle.

The shape of it

POST /submit_signed_transaction

# 1. Enrol once per install to obtain a bearer token
curl -s -X POST https://rpc.futurechain.eu/enroll

# 2. Submit, presenting the token
curl -s -X POST https://rpc.futurechain.eu/submit_signed_transaction \
  -H "X-API-Key: <your-token>" \
  -H "Content-Type: application/json" \
  -d @signed-transaction.json

The transaction must be signed before it is sent — the relay never sees a private key. Signing is over a canonical message encoding, with Ed25519. That is what consensus verifies for a transaction input, so that is what a client must produce.

You may also attach FALCON-512 material. It is carried on-chain and kept with the record, so the history stays verifiable once post-quantum enforcement is switched on — but it is not verified today, and a payment signed with Ed25519 alone is valid. The hybrid requirement at block 810,000 applies to the compliance attestation written by the screening node, not to your transaction signature.

The client SDK is not published yet

A TypeScript SDK exists — HD wallet derivation, byte-exact signing, a PACS.008 builder — but it is not on npm today. There is no npm install line here because it would 404, and sending you to a broken install is worse than saying so.

Until it ships, the read endpoints above need no SDK at all, and writing means reproducing the signing scheme directly. If you are building against the write path now, get in touch first — you should not reverse-engineer it from the wire format.

Rate limits

Endpoint	Limit	Why
/submit_signed_transaction	10 / min / IP	Protects the compliance path, which is the expensive step.
/enroll	5 / hour / IP	Enrolment issues a durable credential.
/register_address	20 / hour / IP	Binds an address to an install; requires a proof-of-control signature.
read endpoints	unauthenticated	Open. Please be reasonable.

Reference

Endpoint summary

The relay exposes a fixed allowlist. Anything not listed is refused at the edge rather than passed to a node.

Endpoint	Auth	Returns
GET /health	none	Liveness.
GET /info	none	Chain tip, latest hash, ISO version, mempool depth.
GET /balance/{addr}	none	Satoshi balance, FTC balance, UTXO count.
GET /get_utxos/{addr}	none	Array of spendable outputs.
GET /transaction/{id}	none	A transaction — recent history only, see above.
POST /enroll	none	A per-install bearer token.
POST /register_address	bearer	Binds an address, needs proof-of-control.
POST /submit_signed_transaction	bearer	Submits a signed, screened payment.

Endpoints not on this list — including anything that would mutate node state — are not reachable from the internet. The relay is a hardened front door, not a full node API.

Read the chain in one command.No key, no account, no SDK.