What ArcX puts on-chain, what runs off-chain and why, and how each off-chain component is protected.
The core idea: We settle tokens and balances on-chain, but run strategy execution and data reporting off-chain. Every off-chain component has a specific practical reason for being off-chain and a defined protection mechanism.
Prerequisites:What is ArcX?, Epoch LifecycleSummary: Five components live on-chain (ST token, EPT token, PointsToken, settlement, and credit balances). Five components run off-chain (matching engine, strategy execution, NAV oracle, credits oracle, points oracle). Each off-chain component is off-chain for a practical reason.
These components live on Starknet. You can verify them directly with a block explorer.
Component
What You Can Verify
ST token
Balances, transfers, total supply per epoch
EPT token
Balances, transfers, accumulated credit balances
PointsToken
Total supply, burns, per-address balances
Settlement
Every deposit, order match settlement, and redemption executes as an on-chain transaction
Credit balances
Per-user credit accrual tracked on-chain
On-chain components are the foundation. Token mechanics (minting, burning, credit accrual, redemption) are verifiable on-chain. If it lives on Starknet, you can check it yourself.The critical distinction: We do not hold your tokens. ST, EPT, and PointsToken are standard tokens on Starknet. Your balances are yours. Our oracles feed data into the contracts (NAV, credit updates, total points), but the contracts enforce the math. No oracle input can directly transfer your tokens to someone else.This means the on-chain layer provides a strong floor of verifiability. Even in a scenario where you distrust every off-chain component, you can still verify your token balances, the total supply, and the settlement of every transaction. The question is not “are my tokens safe?” (they are, on-chain) but “are the oracle inputs accurate?” (that requires the protections described below).
We run five components off-chain. Each one is off-chain for a specific practical reason, not because of a preference for centralization. Click through each tab below to understand what the component does and why it cannot currently run on-chain.
Matching Engine
Strategy Execution
NAV Oracle
Credits Oracle
Points Oracle
What it does: Matches buy and sell orders on the EPT/USDC and ST/USDC orderbooks. Handles cross-matching when a direct deposit triggers mints of both ST and EPT.Why it’s off-chain: Orderbook matching requires iterating over all open orders and booking loops that are not feasible in smart contracts. On-chain orderbooks on Starknet would be too expensive for active trading. Settlement of matched orders happens on-chain. The matching itself is the off-chain step.The pattern: Off-chain matching, on-chain settlement. This is the same architecture used by Extended, Paradex, and other performant DEXes.
What it does: Trades on perp DEXes (Hyperliquid, Paradex, etc.) using deposited capital. Generates PnL and earns exchange points.Why it’s off-chain: The exchanges themselves are off-chain. You cannot execute trades on Hyperliquid from a Starknet smart contract. Strategy execution necessarily happens where the exchanges operate.The pattern: We execute trades on external exchanges using deposited capital. The results (PnL, points) are reported back to the on-chain contracts via oracles.
What it does: Reports the total USDC value of the strategy’s positions. NAV determines how many ST shares you receive on deposit and how much USDC you receive on redemption.Why it’s off-chain: NAV requires reading the strategy’s account positions across multiple perp DEXes. These positions live in exchange accounts, not on-chain. No third-party oracle (Chainlink, Pyth) can compute strategy NAV because it requires access to our exchange account data. This is fundamentally different from price feeds, which aggregate public market data.
What it does: Periodically pushes credit updates to the EPT contract. Each update reports a credits-per-EPT value reflecting the strategy’s activity: open interest, volume, and other metrics that drive exchange point generation.Why it’s off-chain: Credit update values derive from the strategy’s trading activity on exchange accounts. OI and volume data come from the exchanges, not from on-chain sources. Until exchanges expose verifiable activity feeds, this data must be reported by us.
What it does: Reports total points earned by the strategy at epoch maturity. This single number determines the points-per-credit conversion ratio for all EPT holders.Why it’s off-chain: Exchange points are tracked per-account on the exchange platform. They are not public on-chain data. We read our own account’s points balance and report it to the contract.
Every off-chain component has specific safeguards that bound its risk. For each component below: what protects you, how you can verify it, and what bounds the impact.
Matching Engine
Strategy Execution
NAV Oracle
Credits Oracle
Points Oracle
Protection: Settlement is on-chain. The matching engine determines which orders fill, but the actual token transfers execute through Starknet smart contracts. A matching engine bug could cause missed fills, but it cannot move tokens without on-chain settlement.Verification: Every matched trade produces an on-chain settlement transaction. You can verify that your fills correspond to the orders you placed and that the prices match what was quoted.Bounding: If the matching engine goes down, no trades execute, but no funds are at risk. Existing positions (ST, EPT balances) are unaffected. The worst case is missed trading opportunities, not fund loss.
Protection: Strategy PnL depends on market conditions. We have safeguards in place to manage unexpected drawdowns and stop trading under high volatility. EPT accrues credits regardless of strategy PnL, so points exposure is unaffected by strategy performance.Verification: NAV updates reflect strategy performance. You can track the NAV trajectory throughout the epoch. Unusual drawdowns or erratic movements are observable. You can sell your ST on the ST/USDC orderbook to exit at any time during the epoch.Bounding: Epoch isolation prevents compounding. A bad epoch does not automatically roll your capital into the next one. You make a fresh decision each epoch.
Strategy losses could be an expected outcome, not a security incident. The security model protects against oracle manipulation and system failures, not against market risk.
Protection: Deposits automatically revert if NAV data is stale. The contract enforces a maximum staleness window. If the oracle has not updated within that window, no new deposits can execute. Your USDC stays in your wallet. This is an on-chain check that operates without any human intervention.Verification: NAV is derived from positions on perp DEXes that have public dashboards. While you cannot see our exact account, the strategy’s expected exposure is checkable against exchange data. NAV trajectory over an epoch should be consistent with observable market conditions.Bounding: Each epoch is independent. Even if NAV is slightly off for a few updates, the final NAV at maturity determines actual redemptions. A single stale update does not compound across epochs.
Protection: You trust us for oracle updates. We have off-chain safeguards to ensure credit update values accurately reflect strategy activity (OI, volume) on the exchanges.Verification: Users cannot directly see our strategy OI. Instead, you can use visible on-chain signals like total token supply and deployed capital as a reasonableness check. If reported credit updates look consistent with the scale of capital deployed, that is a good sign.
Protection: You trust us for oracle updates, and we have off-chain safeguards to ensure reported points match what the strategy actually earned.Verification: Exact points formulas are not fully transparent. You can still use heuristics and compare reported points against broader market standards, including what other users report for similar capital and activity profiles.
As the protocol matures, we will continue making this layer more robust and more transparent over time, including better transparency dashboards, stronger third-party checks, and custodial/operational safeguards where appropriate.
