Skip to main content
ArcX is designed so that asset ownership, token balances, series settlement, and credit computation happen on-chain. But users should still understand where trust exists today and what risks remain. Two high-level notes:
  • Audits: Nethermind has reviewed our Cairo and Solidity code at commit 8b97dda00f072cac05047a3855afcc91f373d764.
  • Source availability: Contracts are closed source at the beginning. They will be opened up over time once the system has seen enough production use, confidence, and battle testing.

​
Audit

Nethermind has reviewed our Cairo and Solidity code at commit 8b97dda00f072cac05047a3855afcc91f373d764. Read Audits for the authoritative file list, reviewed commit, findings summary, and full report.

​
vToken and Vault Dependencies

The vToken layer records the vault-share position. Depending on the vault design, on-chain state can include:
  • balances, transfers, and total supply
  • NAV or equivalent vault accounting
  • credit-period checkpoints and holder credits
  • deposit and withdrawal state
The vToken does not remove risks inherited from the position behind it. A vault may rely on:
  • the supported input token and its issuer or design
  • an underlying protocol or strategy
  • an operator, borrower, custodian, or other counterparty where applicable
  • cross-chain messaging, token adapters, bridges, or relayers
  • withdrawal processing and available liquidity
Review these dependencies on the vault page. ArcX token accounting cannot guarantee the solvency, availability, or correct behavior of an external system.

​
ST and EPT

All ST and EPT contracts are on-chain. The core contract that handles:
  • series creation
  • splitting vToken into ST + EPT
  • recombining ST + EPT
  • order settlement
  • redemption
also lives on-chain. ArcX does run an off-chain orderbook service to find the best matchable orders. That off-chain component exists because smart contracts cannot do unbounded search over all open orders. But once the service proposes a match set, the orders are checked on-chain against the user’s constraints. That means the on-chain contracts verify that execution remains within:
  • the APR bounds the user set
  • the slippage bounds the user set
  • the settlement constraints for the relevant ST, EPT, and vToken transfers
So ArcX cannot simply route user orders to arbitrary prices, force worse APRs, create invalid fills, or drain funds through the matching service. The off-chain component helps find candidate matches, but settlement and constraints are enforced on-chain.

​
CreditToken Trading

The CreditToken market uses an off-chain matcher with on-chain escrow and settlement:
  • limit orders escrow the offered token and can fill partially
  • cancelling returns the unmatched escrowed remainder
  • market orders are fill-or-kill and enforce quote or slippage bounds
  • market-specific fees are applied during settlement
The matcher can affect availability and execution timing, while the contracts enforce the submitted order constraints. See Trading CreditTokens for the user flow.

​
Credit Oracle and Reward Distribution

Credits are computed from on-chain balances, NAV, and time. The market operator submits a point weight on-chain for each credit period. The market operator does not allocate tokens to individual users. After the point weight is submitted, the contracts automatically apply it to the period’s on-chain credit shares and issue CreditTokens. Off-chain trust remains because:
  • the underlying protocol controls its own points program
  • period weights can depend on external program data
  • data can be delayed, incomplete, revised, or incorrect
  • reward funding and claim eligibility depend on the vault’s configured distribution arrangement
A CreditToken is not a guaranteed direct claim against the underlying protocol.

​
Administrative and Upgrade Risk

ArcX contracts and vault integrations can include privileged roles for upgrades, configuration, pausing, oracle submissions, market activation, fee settings, or operations. Those controls can help respond to incidents, but they also create key-management, governance, and configuration risk. A pause or upgrade can delay deposits, withdrawals, claims, or trading.

​
What to Check

Before depositing or trading, evaluate:
  • the vault’s input token, underlying protocol, yield behavior, and withdrawal terms
  • operator, counterparty, custody, and cross-chain dependencies where applicable
  • credit periods, point weights, and reward-distribution assumptions
Read the Risk Disclosure for the complete user-facing risk summary.