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 verified deployments on ADI testnet. They are the authoritative target for every EIP-712 verifyingContract field.
Every testnet contract is verified on Blockscout — paste any address above into blockscout.ab.testnet.adifoundation.ai to browse source, ABI, and events.

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:
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 runs without MOCK_AUTH_ACCEPT_ALL — every EIP-712 signature is verified for real (ethers.verifyTypedData against the on-chain CTFExchange ORDER_TYPEHASH). Code that signs a placeholder will be rejected with 400 bad_signature. The schema is identical to staging / production — see EIP-712 signing.
Testnet has compliance guards relaxed for integration testing — KYC, geo, and the return-to-source cleared-deposit check are not enforced. Practical consequences:
  • Multi-wallet sub-accounts transact without per-wallet KYC.
  • Every depositing EOA is auto-cleared as a deposit-side withdrawal destination — no destination_not_cleared rejection on first deposit-then-withdraw round-trip.
  • Withdrawal-side EDD enforcement is also suppressed on testnet — a never-deposited destination (e.g. 0x...dEaD) is accepted without destination_not_cleared reject. Production runs the full return-to-source check on every withdrawal address; do not rely on testnet behaviour to validate withdrawal-side EDD logic.
  • Sanctions / geo blocks do not fire.
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.
  • Matcher state is not persisted across redeploys. After a testnet restart, your open orders may disappear (warm-restart of the matcher is planned for staging+).
  • 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 changesVaultFactory, MockCollateral, ConditionalTokens, CTFExchange, NegRiskAdapter, NegRiskCtfExchange, DepositLimitRegistry, Oracle are re-deployed as a single set.
Pre-redeploy assets are stranded. Vault clones 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.

Status page

Real-time status of all environments.

Environment capability matrix