How the vault holds your wallet, how an autonomous service triggers a PLT payment, what stops a compromised key from draining a project, and how CCDX works as the platform's earning engine.
Concordex is the agentic payments & swaps API for Concordium Protocol-Level Tokens (PLTs). Projects register a Concordium wallet with us — keys held inside a hardened vault — and either send PLTs or swap across PLTs through a single REST API. Pay in any PLT, receive in any PLT. Payments + DEX as a service for anything programmatic: AI agents, SaaS backends, treasury bots, settlement engines.
AI-agent platforms paying for tools or inference, SaaS backends running PLT-based billing or payouts, treasury teams that need scoped programmatic spend, and autonomous services that need to settle between themselves on the API layer.
Three things. First, the settlement asset is on-chain (PLTs on Concordium), so every payment and every swap is final and verifiable without a clearing house. Second, the entire flow is built so software is the first-class user — agents and bots get scoped keys and policies, not a payment screen for a human. Third, payments and swaps are unified — pay in one PLT, have the receiver land in another, in a single call.
Software, not humans, initiates the payments and swaps. The API is shaped for programmatic callers — idempotency keys, scoped API keys, webhook callbacks, MCP tool surface (pay, swap, quote, get_balances). An AI agent can call these as native tools the same way it would call a search API.
Concordex runs a hardened HashiCorp-compatible vault (OpenBao) inside a private network. The vault stores each project's Concordium wallet keys, signs transactions on request, and exposes nothing to the public internet. The Concordex API authenticates against the vault on every payment.
Yes. The wallet is yours; the vault holds the keys on your behalf, under a policy you control. Concordex operators cannot unilaterally spend from your wallet — vault unseal is Shamir-quorum, signing is bound to your project's policy, and every operation is audit-logged.
You bring a Concordium account. Concordium accounts can't be generated from raw keys — every account is derived from an Identity Object issued by a regulated identity provider (Notabene, Digital Trust Solutions, etc.) after KYC. If you already have an account (via the Concordium browser wallet or any of the official wallets), you export the keys and upload them to Concordex through a secure channel; we hold them in the vault from then on. If you don't have one yet, the standard Concordium identity flow takes ~10 minutes — we'll point you at it during onboarding.
Because Concordium's identity layer gates account creation, not just transactions. Without an Identity Object (issued by a regulated identity provider after KYC), there's no account to register on chain. Other chains let anyone derive an account from random bytes — Concordium intentionally doesn't. That gate is also what makes the chain identity-aware, which is the property the rest of the platform relies on.
Vault unseal requires a quorum of operator Shamir shares — no single operator can unseal alone. Recovery shares are held offline. Signing operations are gated by project policy, not operator whim. Every action lands in an append-only audit log.
Daily and per-transaction caps, allowed PLT tokens, allowed receiver allow-lists or deny-lists, optional dual-control approval thresholds, and per-key rate limits. Policies are versioned and audit-logged.
API keys can be rotated and revoked individually, without rotating the wallet itself. To rotate the underlying wallet (e.g. after a governance change), one vault operation does it; outgoing webhooks remain wired the same way.
The core surface is small: POST /v1/payments (with optional pay_with for cross-PLT settlement), GET /v1/payments/:id, POST /v1/swaps/quote, POST /v1/swaps, GET /v1/balances, POST /v1/projects/keys, and webhook delivery for finality and rejection. See API examples for full payloads.
Bearer token (Authorization: Bearer sk_live_…). Each API key is scoped to a project, can be limited to specific endpoints, has its own rate limit, and is revocable instantly. Keys are hashed at rest, reverse-indexed inside the vault.
Yes — every Concordex API key gets a corresponding MCP tool set (pay, swap, quote, get_balances) so AI agents can call payments and swaps as native tools. The agentic /demo on this site runs against the same surface. A self-hostable concordex-mcp Python package is available to approved integrators on request.
Sign up a HTTPS endpoint per project. We send a signed POST on payment lifecycle events: payment.submitted, payment.finalised, payment.rejected. Signature verification uses an HMAC shared secret. Retries with exponential backoff up to 24 hours.
Every POST /v1/payments takes an Idempotency-Key header. Replays with the same key return the original payment row instead of double-spending. Critical for any retry-driven caller — including most agent frameworks.
Yes. Set pay_with on the payment to the token you want debited; token stays the receiver's currency. Concordex quotes a swap against the matching pool, executes the trade, and settles atomically — one signed call. You can also call POST /v1/swaps directly to rebalance your own treasury between PLTs. Today the swap orchestrator mediates settlement through a Concordex treasury account; when Concordium ships PLT-locks, the same call settles directly out of LP locks without Concordex touching principal. Slippage caps and allowed-pair policy apply.
Python SDK first, TypeScript next. The HTTP surface is small enough that any language with an HTTP client can integrate directly.
CCDX is the Concordex platform's native Protocol-Level Token on Concordium — fixed supply of 10,000,000. It's the earning engine for the API: every payment routed through Concordex generates a fee, and that fee revenue funds CCDX staking rewards, a lock wallet, and the protocol treasury.
Two stacked fees, two different recipients. The LP fee (10–50 bps, LP-set within bounds) goes to the liquidity provider whose lock was used on that swap — paid in the PLT or CCD being moved. The protocol fee (10 bps on top) is split 45% to CCDX stakers (CCD revenue used to buy CCDX on the open market and distribute pro-rata to active stakers), 45% to a one-year lock wallet (subject to DAO approval, potentially burned), and 10% to the protocol treasury for development, audits and ecosystem growth.
Not Concordex. Liquidity comes from third-party LPs — typically PLT issuers (stablecoin operators, asset-backed token issuers), market makers, and treasuries — who delegate scoped, capped amounts of their PLTs through on-chain PLT locks. The router pulls PLTs out under each lock's rules (max outflow, per-swap cap, per-period cap, allowed receivers, expiry); funds never enter a smart contract. LPs earn the swap fee on every trade routed through their lock, paid in the same PLT or CCD being moved. If you operate a PLT and want to be an anchor LP, get in touch via the access form.
No. Projects integrate with the payments & swaps API and pay fees in CCD or in the PLT being transferred. CCDX is the value-capture token for the platform — you don't need to hold it to make payments or swaps; you hold and stake it if you want to earn from the platform's volume.
Staking is live today on Concordex devnet. Hit POST /v1/stake with an amount, and the vault transfers CCDX from your wallet into the staking pool. Every hour the sweeper drains 10 bps of accumulated swap fees through the per-token / CCD pools, splits the CCD bucket 45/45/10 (stakers / 365-day lock / treasury), and credits stakers pro-rata via a Synthetix-style accumulator — you claim with POST /v1/stake/claim. Live state, APR estimate, recent epochs and lock totals are at /stake. Mainnet activates the same code paths once Concordium PLT-locks ship.
Yes — a public event for ~5% of supply is planned alongside mainnet platform GA. The structure is being finalised to align with the payments + swaps rollout. Waitlist subscribers will hear about it first.
A token implemented natively at the Concordium protocol level, not as a smart contract. PLTs live on PL-accounts; the protocol itself enforces transfer rules. Crucially, smart contracts can't hold PLTs — removing a huge class of custodial and contract-exploit risk that breaks normal payment and DEX APIs on other chains.
Devnet today: EURX, USDX and CCDX — Concordex-issued PLTs we mint at genesis on our own P10 chain, used for end-to-end testing without touching the public network. On mainnet, regulated PLTs already exist and will be supported: Euro stablecoins (EURR, VEUR, eEUR), USD stablecoins (USDR, eUSD, USC, t-USDC, t-USDT), GBP/CHF/SGD stablecoins (VGBP, VCHF, eGBP, eSGD) and asset-backed tokens like eGOLD. New PLTs land at the protocol level continuously and are picked up by per-project policy without an integration. Note: CCD itself is the chain's native token, not a PLT; in Concordex it plays the role of universal fee + settlement asset. Legacy CIS-2 smart-contract tokens are not supported through this API — only protocol-level tokens.
Concordium finalises in seconds. Our API returns immediately on submission with a tx hash; we poll for finality and emit a webhook the moment it lands. Most payments are end-to-end final inside 10 seconds.
Concordium energy fees are paid in CCD by the project wallet. We surface the actual fee on every payment record. Projects paying out in non-CCD PLTs keep a small CCD balance for fees — or use the fee-sponsorship primitive to fold fees into the payment price.
Yes — Concordium has a built-in identity layer. Every account is provably linked (under privacy-preserving cryptography) to an identity issuer, so compliance and dispute resolution can be exercised when legally required, without exposing private data to the public chain.
Yes — live today on Concordex devnet, our own Concordium P10 chain. /v1/payments, /v1/swaps, /v1/lp/deposit and the agentic /demo all settle real Protocol-Level Token transfers, and every transaction is verifiable on our devnet block explorer. Mainnet alpha follows once Concordium ships the PLT-lock primitive in protocol — the API surface stays unchanged through that migration. Request access from the homepage to be in the next cohort.
Three things. (1) Every key is scoped — a payment key can't mint new keys; a read-only key can't pay. (2) Project policy enforces daily caps, per-transaction ceilings and allow-lists at the vault layer, not the API layer. (3) Revoking a key is instant and the rest of the project keeps running.
Vault custody and scoped policies dramatically reduce custodial and contract-exploit risk. They don't eliminate the operational risk of your own code (a buggy agent can still pay the wrong recipient inside its allow-list) or the market risk of whichever PLT you're settling in. You own the policies; we enforce them.
Access depends on the identity assurance level we hold for a project sponsor and applicable local regulation. We review each cohort directly. Concordium's identity framework lets us support compliant operations without turning the layer into a one-size-fits-all gate.
Submit the access form on the homepage with a concrete use case — what you'd pay or swap, how often, in which PLT. Specific plans get prioritised.