Search

Search for projects by name

SummaryValue LockedActivityMilestones & IncidentsRisk summaryRisk analysisTechnologyState derivationOperatorWithdrawalsPermissionsSmart contracts

Pay Chain logoPay Chain

Badges

About

Pay Chain is a Validium built on the Polygon CDK stack. It is used as the infrastructure for the Wirex non-custodial debit cards.

Value Locked
$95.81 K0.35%
Canonically Bridged
$95.81 K
Externally Bridged
$0.00
Natively Minted
$0.00
View TVL Breakdown
  • Tokens
  • Daily UOPS
    0.000.00%
  • 30D ops count
    1.24 K
  • Type
    Validium
  • Purposes
    Universal, Payments
    • Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    Pay Chain is a Validium built on the Polygon CDK stack. It is used as the infrastructure for the Wirex non-custodial debit cards.

    Recategorisation

    174d
    10h
    23m
    16s

    The project will be classified as "Other" due to its specific risks that set it apart from the standard classifications.

    The project will move to Others because:

    There are less than 5 external actors that can attest data availability

    Consequence: projects without a sufficiently decentralized data availability committee rely on few entities to safely attest data availability on Ethereum. A small set of entities can collude with the proposer to finalize an unavailable state, which can cause loss of funds.

    Learn more about the recategorisation here.

    Value Locked
    Canonical
    External
    Native
    Activity
    Pay Chain
    Ethereum
    Milestones & Incidents

    Wirex Pay Chain Protocol Launch

    2024 Aug 28th

    Wirex Pay Chain launches officially, integrated with Polygon AggLayer.

    Learn more
    Risk summary

    Funds can be lost if

    1. the proof system is implemented incorrectly,
    2. the external data becomes unavailable (CRITICAL).

    Funds can be frozen if

    1. the sequencer refuses to include an exit transaction (CRITICAL).

    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. Although the functionality exists in the code, it is currently disabled.

    State validation

    ZK proofs (ST, SN)

    STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.

    Data availability

    External (DAC)

    Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 1/2 that is tasked with protecting and supplying the data.

    Exit window

    None
    The Security Council can remove the delay on upgrades.

    Even though there is a 10d Timelock for upgrades, forced transactions are disabled. Even if they were to be enabled, user withdrawals can be censored up to 15d.

    Proposer failure

    Self propose

    If the Proposer fails, users can leverage the source available prover to submit proofs to the L1 bridge. There is a 5d delay for proving and a 5d delay for finalizing state proven in this way. These delays can only be lowered except during the emergency state.

    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.

    1. PolygonRollupManager.sol - Etherscan source code, _verifyAndRewardBatches function

    Zero knowledge STARK and SNARK cryptography is used

    Despite their production use zkSTARKs and zkSNARKs 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. In addition zkSNARKs require a trusted setup to operate.

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

    Data is not stored on chain

    The transaction data is not recorded on the Ethereum main chain. Transaction data is stored off-chain and only the hashes are posted onchain by the Sequencer, after being signed by the DAC members.

    • Funds can be lost if the external data becomes unavailable (CRITICAL).

    1. PolygonValidiumStorageMigration.sol - Etherscan source code, sequenceBatchesValidium function
    Learn more about the DA layer here: Pay Chain DAC logoPay Chain DAC
    State derivation
    Node software

    Node software can be found here.

    Compression scheme

    No compression scheme yet.

    Genesis state

    The genesis state, whose corresponding root is accessible as Batch 0 root in the getRollupBatchNumToStateRoot(5,0) method of PolygonRollupManager, is available here.

    Data format

    The trusted sequencer request signatures from DAC members off-chain, and posts hashed batches with signatures to the WirexPayChainValidium contract.

    Operator

    The system has a centralized sequencer

    Only a trusted sequencer is allowed to submit transaction batches. A mechanism for users to submit their own batches is currently disabled.

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

    • Funds can be frozen if the sequencer refuses to include an exit transaction (CRITICAL).

    1. WirexPayChainValidium.sol - Etherscan source code, onlyTrustedSequencer modifier

    Users can't force any transaction

    The mechanism for allowing users to submit their own transactions is currently disabled.

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

    1. WirexPayChainValidium.sol - Etherscan source code, forceBatchAddress address
    Withdrawals

    Regular exit

    The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is proven the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

    1. PolygonZkEvmBridgeV2.sol - Etherscan source code, claimAsset function
    Permissions

    The system uses the following set of permissioned addresses:

    Sequencer 0x49a1…EAdA

    Its sole purpose and ability is to submit transaction batches. In case they are unavailable users cannot rely on the force batch mechanism because it is currently disabled.

    Proposer (Trusted Aggregator) (2) 0x6329…f7ab0x20A5…51dE

    The trusted proposer (called Aggregator) provides ZK proofs for all the supported systems. In case they are unavailable a mechanism for users to submit proofs on their own exists, but is behind a 5d delay for proving and a 5d delay for finalizing state proven in this way. These delays can only be lowered except during the emergency state.

    SecurityCouncil 0x37c5…Dcb6

    A Gnosis Safe with 6 / 8 threshold. The Security Council is a multisig that can be used to trigger the emergency state which pauses bridge functionality, restricts advancing system state and removes the upgradeability delay.

    Used in:

    SecurityCouncil participants (8) 0xFe45…2e4b0xaF46…261D0xBDc2…FEFf0x4c16…88910x3ab9…D6220x49c1…0E860x9F7d…86A00x2188…1C28

    Those are the participants of the SecurityCouncil.

    Forced Batcher LocalAdmin

    Sole account allowed to submit forced transactions. If this address is the zero address, anyone can submit forced transactions.

    RollupManagerAdminMultisig 0x242d…3e21

    A Gnosis Safe with 2 / 3 threshold. Admin of the PolygonRollupManager contract, can set core system parameters like timeouts and aggregator as well as deactivate emergency state. They can also upgrade the WirexPayChainValidium contracts, but are restricted by a 10d delay unless rollup is put in the Emergency State.

    Used in:

    RollupManagerAdminMultisig participants (3) 0x4c16…88910xA0B0…f2270xEad7…9dB2

    Those are the participants of the RollupManagerAdminMultisig.

    LocalAdmin Forced Batcher

    Admin and ForceBatcher of the WirexPayChainValidium contract, can set core system parameters like timeouts, sequencer, activate forced transactions, and set the DA committee members in the WirexPayChainDAC contract.

    WirexPayChainDAC Upgrader 0xb860…2cfe

    Can upgrade the WirexPayChainDAC contract and thus change the data availability rules any time.

    Smart contracts
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    The system consists of the following smart contracts on the host chain (Ethereum):

    WirexPayChainDAC 0x755e…38a5Implementation (Upgradable)Admin

    Validium committee contract that allows the owner to setup the members of the committee and stores the required amount of signatures threshold.

    Can be upgraded by:
    WirexPayChainDAC Upgrader

    Upgrade delay: None

    WirexPayChainValidium 0x7825…94c9Implementation (Upgradable)Admin

    The main contract of the Pay Chain. Contains sequenced transaction batch hashes and forced transaction logic.

    Can be upgraded by:
    RollupManagerAdminMultisig

    Upgrade delay: None

    Implementation used in:

    Verifier 0x0775…Df81

    An autogenerated contract that verifies ZK proofs in the PolygonRollupManager system.

    Implementation used in:

    PolygonRollupManager 0x5132…7aB2Implementation (Upgradable)Admin

    It defines the rules of the system including core system parameters, permissioned actors as well as emergency procedures. The emergency state can be activated either by the Security Council, by proving a soundness error or by presenting a sequenced batch that has not been aggregated before a 7d timeout. This contract receives L2 state roots as well as ZK proofs.

    Can be upgraded by:
    RollupManagerAdminMultisig

    Upgrade delay: None

    Proxy used in:

    Bridge 0x2a3D…2EDeImplementation (Upgradable)Admin

    The escrow contract for user funds. It is mirrored on the L2 side and can be used to transfer both ERC20 assets and arbitrary messages. To transfer funds a user initiated transaction on both sides is required. This contract can store any token.

    Can be upgraded by:
    RollupManagerAdminMultisig

    Upgrade delay: None

    Proxy used in:

    GlobalExitRootV2 0x580b…3CFbImplementation (Upgradable)Admin

    Synchronizes deposit and withdraw merkle trees across L1 and the L2s. The global root from this contract is injected into the L2 contracts.

    Can be upgraded by:
    RollupManagerAdminMultisig

    Upgrade delay: None

    Proxy used in:

    Timelock 0xEf14…A4EF

    Contract upgrades have to go through a 10d timelock unless the Emergency State is activated. It can also add rollup types that can be used to upgrade verifier contracts of existing systems. It is controlled by the ProxyAdminOwner.

    Implementation used in:

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

    Generic escrow 0x2a3D…2EDeImplementation (Upgradable)Admin

    Proxy used in:

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is a 10d delay on code upgrades.

    1. State injections - stateRoot and exitRoot are part of the validity proof input.