Testing

The test hub

The public test hub is https://proxy-api.infinimesh.net, with its API under https://proxy-api.infinimesh.net/v1. Pass the origin as baseUrl: the SDK adds /v1 (a trailing /v1 is accepted too). It runs on test networks only. Call it from your backend with your secret key, or from a page with your project id. Its gateway never takes a secret key from a browser.

Chain	RPC	Explorer
`eip155-8888` (Continuum public testnet)	`https://public-testnet-evm.c8ntinuum.link`	testnet.ctmscan.io
`eip155-1` (a mainnet fork: chain id 1)	`https://eth-testnet.infinimesh.net`	none: query the RPC
`solana-localnet`	`https://sol-testnet.infinimesh.net` (WebSocket `wss://sol-testnet.infinimesh.net`)	none: query the RPC

Test funds: CTM from the Continuum testnet faucet. For the other test assets, swap CTM for them through the test hub itself, or ask the hub team.
Lanes: the test hub offers wrap-native, evm-permit2, swap-token and solana-escrow; not evm-3009 or open-flow yet.

The test hub has its own catalog, and its contract addresses change when it is redeployed. Build everything from the catalog.

Keys and project ids

Your organization, its project and its keys live in the hub dashboard, proxy-admin.infinimesh.net for the test network: the API has no sign-up and no key routes.

A secret API key (c8n_sk_…) for your servers and scripts: make one for your project, and keep it in your secret store or in a git-ignored .env file as HUB_API_KEY.
The project id (c8n_pk_…) for your web pages: it is on the project page, public by design. List the origins of the pages that use it (http://localhost:5173, for example, while you develop).

Check a key with one call that needs it:

curl -sS "https://proxy-api.infinimesh.net/v1/orders?limit=1" \
  -H "x-api-key: $HUB_API_KEY" \
  -H "X-Infinity-Subject: default"

A 200 means the key is accepted. A 401 means it is not: EPX0001 for a value that is not in the key’s format (a typo, a stray space, a truncated copy), EPX0002 for an unknown, revoked or expired key. Fix it before trying again: 20 refused credentials within a minute lock your IP out of every call for the rest of that minute (EPX0081). The node quickstart’s pnpm smoke starts with the same check. To try the flows in a browser without a server, use the project id: list the page’s origin on the project (http://localhost:5173 for the bridge demo’s pnpm dev; the hosted demo, https://demo.infinimesh.net, too if you connect it with your project id), or leave the list empty while you test (Browser apps).

Test wallets

Use keys made for testing, holding nothing on any real network.

A test “Ethereum” that is a mainnet fork answers chain id 1, exactly like real Ethereum. A transaction or a Permit2 signature made for the fork is valid on real mainnet too: anyone can replay it there. Never test with a key that holds real funds, and pin the fork (below) so the SDK refuses to sign if your RPC points at the real network.

On a server, or in a script:

import { privateKeyToAccount } from "viem/accounts";
import { evmWalletFromAccount } from "@c8ntinuum/infinity-interop-sdk/evm";
import { solanaRpc, solanaWalletFromKeypair } from "@c8ntinuum/infinity-interop-sdk/solana";

const evm = evmWalletFromAccount({
  account: privateKeyToAccount(process.env.EVM_PRIVATE_KEY as `0x${string}`),
  rpcUrls: { 1: process.env.RPC_EIP155_1!, 8888: process.env.RPC_EIP155_8888! },
  chainInstances: { 1: { blockNumber: 26_090_310n, blockHash: "0x…" } }, // a block of the fork
});
const solana = await solanaWalletFromKeypair({
  secretKey: process.env.SOLANA_SECRET_KEY!,
  rpc: solanaRpc(process.env.RPC_SOLANA_LOCALNET!), // to send refunds; orders are sent by a solver
});

Chain-instance pins

A pin names one block, by number and hash, that only the chain you mean contains. Before the first signature or transaction on that chain, the wallet adapter reads that block and refuses unless the hash matches (WalletError, reason wrong-chain). Ask the hub team for a block of their fork: it changes whenever they reset it. The examples read pins from .env as PIN_EIP155_<chainId>=<blockNumber>:<blockHash>. See Chain-instance pins.

The examples

The SDK repository has three runnable examples, each configured by a git-ignored .env copied from its .env.example:

Example	What it is
`examples/node-quickstart`	scripts: `pnpm smoke`, `catalog`, `quote`, `bridge`, `orders`, `refund`. Its `.env` holds `HUB_BASE_URL` and `HUB_API_KEY`, and test-network wallet keys for `bridge` and `refund`
`examples/proxy-server`	a partner backend: holds your secret key (`HUB_API_KEY`), serves the demo through the proxy, and relays the demo’s RPC calls. It keeps users apart by `X-Infinity-Subject`, checked by the subject canary at start-up, unless `HUB_USER_SCOPE=ownership`. It has no login of its own: it listens on this computer only unless you set `HOST`, and answers other origins only if you list them in `CORS_ORIGINS`
`examples/bridge-demo`	a bridge screen in the browser, with two views switched from its header: Simple, a swap page with the essentials (tokens and amount, the quote, one button, the route as the order moves, your orders and refunds), and Dev, the walk-through (quote, the checks, execute, track, history, refunds, the wire calls). It connects with your project id (App ID) or, on the dev view, through your proxy server. A hosted copy runs at demo.infinimesh.net

Start with the smoke test. It checks your key with one call, reads the catalog, then asks for a preview and a quote on every route and runs the pre-signing checks on each quote. It needs no funds, and signs nothing:

pnpm smoke --recipient-evm 0x… --recipient-solana <base58>

Then one order per lane you offer, with small amounts:

pnpm bridge --from eip155-8888:ctm --to eip155-1:weth --amount 3

To run the browser demo through the proxy, start the proxy first (pnpm --filter @c8ntinuum-examples/proxy-server dev, then pnpm --filter @c8ntinuum-examples/bridge-demo dev). Through the proxy, the demo reaches the RPCs through its relay, POST /api/rpc/<chain>, so a keyed RPC URL stays on the server. The demo’s Connection card can also call the test hub directly, with your project id: every route but the order history is open that way.

Testing a refund

There is no way to force a refund: an order becomes refundable only once its deadline has passed with no fill (see Refunds). On a test hub:

Get an order nobody will fill. Ask the hub team, or open one on the escrow yourself with an output no solver will fill (an absurd amount) and a short deadline.
Wait in real time, until the source chain’s clock is past the deadline and the hub’s destination observer has read past it too. checkEvmRefund says not-yet until then.
Refund it with refundEvmOrder (or pnpm refund --id <onchainOrderId>), and check that the escrow paid the wrapped coin back.

Never move a shared test chain’s clock (evm_increaseTime, evm_mine with a timestamp) to reach a deadline: every other user of that fork, and the hub’s own observers, run on the same clock.

Before going live

Use the production hub’s origin, and a secret key made for production, kept on your servers only.
List your production pages’ origins on your project, if your pages use the project id.
Keep pins only for test chains: a real network’s chain id is unique.
Put your own authentication in resolveUser if you serve pages through createInteropProxy.
Run the smoke test against production before you open the flow to users.

Get started

Core concepts

Resources

API reference

SDK

SDK reference

The test hub

Keys and project ids

Test wallets

Chain-instance pins

The examples

Testing a refund

Before going live

​The test hub

​Keys and project ids

​Test wallets

​Chain-instance pins

​The examples

​Testing a refund

​Before going live

The test hub

Keys and project ids

Test wallets

Chain-instance pins

The examples

Testing a refund

Before going live