Search

Search for projects by name

SummaryValue SecuredMilestones & IncidentsRisk summaryRisk analysisRollup stageTechnologyData availabilityOperatorWithdrawalsPermissionsSmart contracts

Paradex logoParadex

There are impactful changes and part of the information might be outdated.

Badges

About

Paradex is a high-performance crypto-derivatives exchange built on a Starknet Appchain.

Value secured
$52.54 M9.67%
Canonically Bridged
$0.00
Natively Minted
$0.00
Externally Bridged
$52.54 M
View TVS Breakdown
  • Tokens
  • Past day UOPS
    No data
  • 30D ops count
    No data
  • Gas token
    ETH
  • Stage
  • Type
    ZK Rollup
  • Purposes
    Universal, Exchange
    • Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    Paradex is a high-performance crypto-derivatives exchange built on a Starknet Appchain.

    Value Secured

    2024 Apr 23 — 2025 Apr 23

    Total value securedTotal
    $52.54 M9.67%
    Canonically BridgedCanonically Bridged ValueCanonical
    $0.000.00%
    Natively MintedNatively Minted TokensNative
    $0.000.00%
    Externally BridgedExternally Bridged ValueExternal
    $52.54 M9.67%
    View TVS breakdown
    Milestones & Incidents

    Perpetual Options Launch

    2025 Apr 1st

    Paradex opens perpetual options trading to all users.

    Learn more

    Paradex exits Open Beta

    2024 Nov 7th

    Paradex launches XP Warzone Season 1 and exits Open Beta.

    Learn more
    Risk summary

    Funds can be lost if

    1. the proof system is implemented incorrectly.

    Funds can be frozen if

    1. the operator censors withdrawal transaction.

    Users can be censored if

    1. the operator refuses to include their transactions.

    MEV can be extracted if

    1. the operator exploits their centralized position and frontruns user transactions.
    Risk analysis
    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    No mechanism

    There is no mechanism to have transactions be included if the sequencer is down or censoring.

    State validation
    ZK proofs (ST)

    STARKs are zero knowledge proofs that ensure state correctness.

    Data availability
    Onchain (SD)

    All of the data (SD = state diffs) needed for proof construction is published onchain.

    Exit window
    None

    There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.

    Proposer failure
    Cannot withdraw

    Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.

    Rollup stageParadexParadex is a
    Stage 0
    ZK Rollup.
    There is no available node software that can reconstruct the state from L1 data, hence there is no way to verify that this system is a rollup.

    Learn more about Rollup stages
    Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.
    Technology

    Validity proofs ensure state correctness

    Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.

    Zero knowledge STARK cryptography is used

    Despite their production use zkSTARKs proof systems are still relatively new, complex and they rely on the proper implementation of the polynomial constraints used to check validity of the Execution Trace.

    • Funds can be lost if the proof system is implemented incorrectly.

    1. STARK Core Engine Deep Dive
    Data availability

    All data required to reconstruct rollup state is published on chain

    State diffs are publish onchain as blob or calldata on every state update. The state diffs contain information on every contact whose storage was updated, and additional information on contract deployments. From diffs full system state can be recovered. Contracts’ code is not published on L1, but can be trustlessly verified if available elsewhere.

    1. On-Chain Data - Starknet documentation
    Learn more about the DA layer here: Ethereum logoEthereum
    Operator

    The system has a centralized operator

    The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.

    • MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

    Users can't force any transaction

    There is no general mechanism to force the sequencer to include the transaction.

    • Users can be censored if the operator refuses to include their transactions.

    1. Censorship resistance of Starknet - Forum Discussion
    Withdrawals

    Regular messaging

    The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks. Note that the message request can be censored by the Sequencer.

    • Funds can be frozen if the operator censors withdrawal transaction.

    1. Withdrawing is based on l2 to l1 messages - Starknet documentation

    Emergency exit

    There is no generic escape hatch mechanism as Starknet cannot be forced by users into a frozen state. Note that a freezing mechanism on L2, to be secure, requires anti-censorship protection.

    Permissions

    Ethereum

    Roles:

    Operator 0xC70a…4fe2

    Permissioned to regularly update the state of the L2 on L1. Each state update must have been proven via the SHARP verifier and contains state diffs for data availability.

    Governor Paradex Multisig

    Permissioned to manage the Operator role, finalize state and change critical parameters like the programHash, configHash, or message cancellation delay in the core contract.

    Actors:

    Paradex Multisig 0x0a64…6B93
    • A Multisig with 2/5 threshold.
    • A Governor.
    • Can upgrade the implementation of Paradex.

    Participants (5):

    0x64F4…57700x2871…B4030x804d…C81f0xBF6a…B4A60x5923…8558
    Paradex Multisig 2 0xFF57…61C0
    • A Multisig with 3/5 threshold.
    • Is allowed to interact with USDC Bridge - disable the withdrawal limit.
    • Is allowed to interact with USDC Bridge - enable the withdrawal limit.
    • Is allowed to interact with USDC Bridge - manage critical access control roles and the role that can upgrade the implementation.
    • Can upgrade the implementation of USDC Bridge.

    Participants (5):

    0x3552…15120xFE59…b5710x661B…31550x921D…C79B0x31fB…E7A6
    SHARP Multisig 0x21F9…AEc4
    • A Multisig with 2/4 threshold.
    • Can upgrade the implementation of SHARPVerifierCallProxy.

    Participants (4):

    0x0405…84880x5923…85580xebc8…fD7F0x955B…2Fec

    Used in:

    EOA 1 0xa1F2…E77c

    Can upgrade the implementation of USDC Bridge.

    Smart contracts
    Note: Contracts presented in this section had their implementations updated since the last time our team looked at this project. The information presented may be inaccurate.
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    Paradex 0xF338…3640Implementation (Upgradable)Admin

    Central rollup contract. Receives (verified) state roots from the Sequencer, allows users to consume L2 -> L1 messages and send L1 -> L2 messages. Critical configuration values for the L2’s logic are defined here by various governance roles.

    Can be upgraded by:
    Paradex Multisig with no delay

    Implementation used in:

    SHARPVerifierCallProxy 0x4731…Db60Implementation (Upgradable)Admin

    Upgradable contract through which the SHARPVerifier can be called. This allows SHARP Multisig to change the otherwise immutable verifier contract with 0s delay.

    Can be upgraded by:
    SHARP Multisig with no delay

    Proxy used in:

    SHARPVerifier 0x9fb7…1942

    Shared Starkware SHARP verifier used collectively by Starknet and other SN stack and StarkEx projects. It receives STARK proofs from the Prover and verifies the integrity of the offchain execution including a correctly computed state root which is part of the Program Output.

    Proxy used in:

    MemoryPageFactRegistry 0xe583…C460

    Auxiliary to the SHARPVerifier contract: Verified ‘memory fact pages’ get stored here. This is important as it registers all necessary onchain data produced by the verifier.

    Proxy used in:

    There are impactful changes to the following contracts, and part of the information might be outdated.
    USDC Bridge 0xE3cb…3Db3Implementation (Upgradable)AdminAdmin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: USDC.

    Can be upgraded by:
    EOA 1 with no delayParadex Multisig 2 with no delay

    Value Secured is calculated based on these smart contracts and tokens:

    There are impactful changes to the following contracts, and part of the information might be outdated.
    Escrow for USDC 0xE3cb…3Db3Implementation (Upgradable)AdminAdmin

    Paradex USDC Escrow. The current bridge cap is 60.00 M USDC.

    Can be upgraded by:
    USDC Escrow owner with 0s delay

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).