Skip to main content

Testnet (open)

Testnet is the default environment for all examples in this documentation. Access is open — no partner agreement required.

Testnet contract addresses

These are the current deployments on ADI testnet. Orders are signed under the domain { name: "PredictStreet", version: "1", chainId: 99999, verifyingContract }. Use NegRiskCtfExchange when the market’s negRiskEligible is true, and CTFExchange (binary) otherwise. An order signed against the wrong exchange is rejected with bad_signature. Vault operations (withdrawals, split / merge / convert) are not signed against any address in this table. They use your own vault’s domain (name: "PredictStreetVault", verifyingContract = your vault address from VaultFactory.vaultOf(yourWallet)), never the VaultFactory address.
Paste any address above into blockscout.ab.testnet.adifoundation.ai to browse its transactions, token transfers and emitted events. Contract source is not verified there, so take function signatures from the Contracts reference and request ABIs from your onboarding contact rather than relying on the explorer.

Read-at-runtime — GET /api/platform/contracts

The address table above is the human-readable form of the canonical contract registry. For SDK code prefer the runtime endpoint:
  • usdcEip712 is the name / version of the USDC contract’s EIP-712 domain. Use exactly these values when you build the Permit for a gasless deposit; any other values recover a different signer and the relay answers permit_signer_mismatch.
  • ccipBridge carries { destChainSelector } for cross-chain withdrawals over Chainlink CCIP, or null when the environment has no bridge configured (cross-chain withdrawals are then unavailable).
  • generatedAt is the time the response was generated, not a deploy timestamp — diff the addresses to detect a redeploy.
Public, unauthenticated, rate-limited at 60/min/ip. Source-of-truth is the platform deploy environment — CI/CD updates the env in lockstep with each contract deploy, so the response cannot lag platform state. Quickstart code samples should fetch() this at boot rather than hardcoding constants — eliminates the entire class of bugs from a stale prose-page after a redeploy. wrappedCollateral is null on both testnet and mainnet — the field is reserved for future deployments and is not used by today’s NegRisk markets.

Getting testnet USDC

MockCollateral (0x979696A1B62d4c0F0390124447c065798ee4c70c) exposes a public mint(address to, uint256 amount) on testnet — anyone can mint themselves mUSDC. After minting, you still need to deposit into your vault: see Vaults.

Testnet caveats

Testnet verifies every order signature for real, against the same Order struct and EIP-712 domain the on-chain exchange hashes (CTFExchange for binary markets, NegRiskCtfExchange for neg-risk markets). The platform rebuilds that struct itself:
  • signer = your wallet
  • maker = your vault
  • taker = the zero address
  • signatureType: 1
  • salt = the request nonce
  • expiration = the request expiry
  • feeRateBps = the market’s feeTakerBps
  • side = 0 for buy, 1 for sell
  • tokenId / makerAmount / takerAmount derived from the market, outcome, side, price and quantity
A signature that doesn’t verify is not an HTTP error. POST /api/orders/place answers 201 with status: "REJECTED" and code: "bad_signature"; in /api/orders/place-batch the rejected entry also carries success: false. details carries recovered, expected_signer and platform_canonical_struct so you can diff your struct field by field. Always branch on status, not on the HTTP code. The schema is identical to staging / production — see EIP-712 signing.
Testnet relaxes some off-chain compliance checks for integration testing (see the capability matrix), so AML and sanctions outcomes there are not representative. The on-chain controls still apply: each wallet’s tier, deposit caps and withdrawal restriction are set in DepositLimitRegistry from its KYC level, so a wallet whose tier is not set cannot deposit and a Basic-level wallet cannot withdraw. Testnet cap figures can differ from production — read them from GET /api/me/deposit-limits.Production enforces the full compliance chain. Don’t rely on testnet outcomes to validate your prod compliance flow — sanity-check against the staging / production controls before going live.
  • Resting orders survive a matcher restart: on start the matcher reloads every open and partially filled order before it resumes matching. Don’t re-place your book after a restart; reconcile against GET /api/orders/open instead.
  • Oracle on testnet resolves against mock data. Do not use testnet resolution for real backtesting.
  • Faucet, admin pause / resume / cancel, and platform kill-switch can be triggered at any time during partner testing windows — expect occasional disruptions.

Testnet redeploys: what to expect

Testnet contracts get redeployed periodically (chain upgrades, schema changes, security patches). When that happens every contract address on this page changes — VaultFactory, MockCollateral, ConditionalTokens, CTFExchange, NegRiskAdapter, NegRiskCtfExchange, DepositLimitRegistry, Oracle, NegRiskOracle, MulticallExecutor are re-deployed as a single set.
Pre-redeploy assets are stranded. Vaults and balances on the old VaultFactory / MockCollateral / ConditionalTokens remain on-chain but are unusable on the new platform — the new exchange does not recognise them. Recovery via the emergency-withdraw timelock returns the original (now stale) tokens; their economic value on the new platform is zero.After a redeploy:
  • Mint fresh testnet MockCollateral (mUSDC) using the new address from the table above.
  • Re-deposit into a fresh vault via the new VaultFactory.
  • Re-sign EIP-712 orders against the new verifyingContract (the new CTFExchange / NegRiskCtfExchange).
We post the redeploy notice to integration partners over the partner Slack channel and update this page within the same window — always re-fetch addresses after a partner-channel ping rather than caching them in your config indefinitely.
Mainnet redeploys are not done in-place. Any contract change on mainnet ships as a new deployment with a coexistence period and explicit migration instructions delivered via the partner channel.

Staging (on request)

Production-like environment with real AML provider, real data-source adapters, real on-chain deployments on a production-ready chain. Used for the pre-launch dry-run before a new market opens to real users. Access requires:
  1. A signed partner agreement (NDA + API access terms).
  2. A whitelisted source IP for the internal network (staging surfaces are gated behind VPN).
  3. A dedicated partner account provisioned by ops.
Contact partners@predictstreet.com for staging access.

Mainnet (partner onboarding)

Production environment. Base URL, chain ID, and contract addresses are delivered to partners at onboarding as part of the live-rollout runbook. Do not hardcode mainnet values from this documentation — always read them from the onboarding package so configuration remains auditable.

Partner onboarding

Request mainnet access and onboarding runbook.

Mainnet web app

The public retail site. The testnet equivalent is WEB_APP in the testnet endpoints above.

Environment capability matrix