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: All ArcX contracts have been audited by Nethermind. The report is available publicly.
  • 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

All ArcX contracts have been audited by Nethermind. Read the full report: NM_0901_arcx_karnot_FINAL.pdf

​
vToken

The vToken contracts are on-chain and self-custodial.
  • user balances, transfers, supply, and NAV all live on-chain
  • credit computation also happens on-chain
  • ArcX does not take custody of user funds inside the vToken system
Today, ArcX uses Wildcat to lend capital to market makers. The movement of funds from Starknet into Wildcat is handled through smart contracts, not through ArcX-controlled wallets. That means ArcX does not become the custodian of funds during the lending flow. But users are still taking borrower default risk through the underlying market maker relationship. ArcX partners with market makers and lists them on the platform, but ArcX does not guarantee borrower performance. If a market maker fails to repay or defaults on its borrowing obligations, that risk ultimately sits with the users who chose to allocate capital to that vToken. Users should treat a vToken as both:
  • an on-chain self-custodial position
  • an economic exposure to the creditworthiness and execution quality of the underlying market maker

​
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.

​
Credit Oracle and Reward Distribution

Credits are computed on-chain, but the rewards side still depends on off-chain information and market maker reward delivery. ArcX uses period weights to reflect relative reward contribution across credit periods. Those weights are submitted through an oracle process and are used to determine how many CreditTokens are minted for each period. The oracle does not assign rewards to individual users. It reports period weights, and the contracts apply those weights to on-chain credit balances. When rewards are shared, the relevant market maker funds the CreditToken distribution contract with rewards received for that strategy. CreditToken holders claim from that contract according to the contract logic. This means users are taking several risks:
  • the underlying protocol controls its own points program and reward allocation
  • period weights depend on information from the market maker
  • the market maker must receive rewards and fund the distribution contract
See Risk Disclosure for the full list of CreditToken and reward-distribution risks.

​
What Users Should Actually Check

Before allocating capital, users should evaluate:
  • the market maker behind the vToken
  • the Wildcat borrowing setup and borrower risk
  • the terms of the specific series they are trading
  • the current credit-oracle and reward-distribution assumptions
The smart-contract layer makes custody and settlement transparent. It does not remove the need to evaluate counterparty risk, operational risk, and oracle trust.