Lumia Prism
Badges
About
Lumia is a Validium built on the PolygonCDK stack focusing on real world assets, restaking and account abstraction.
Badges
About
Lumia is a Validium built on the PolygonCDK stack focusing on real world assets, restaking and account abstraction.
Recategorisation
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:
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.
Funds can be stolen if
Funds can be lost if
Funds can be frozen if
Users can be censored if
MEV can be extracted if
Sequencer failure
No mechanismThere 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
NoneEven 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.
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 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).
Set of parties responsible for signing and attesting to the availability of data.
There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known.
There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer.
The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
Architecture
Polygon CDK validiums utilize a data availability solution that relies on a Data Availability Committee (DAC) to ensure data integrity and manage off-chain transaction data. This architecture comprises the following components:
- Operator: A trusted entity that collects transactions, computes hash values for the transaction batch, and then requests and collects signatures from Committee members.
- Data Availability Committee (DAC): A group of nodes responsible for validating batch data against the hash values provided by the operator (sequencer), ensuring the data accurately represents the transactions.
- PolygonCommittee Contract: Contract responsible for managing the data committee members list.
Each DAC node independently validates the batch data, ensuring it matches the received hash values. Upon successful validation, DAC members store the hash values locally and generate signatures endorsing the batch’s integrity. The sequencer collects these signatures and submits the transactions batch hash together with the aggregated signature on Ethereum. The PolygonCommittee contract is used during batch sequencing to verify that the signature posted by the sequencer was signed off by the DAC members stored in the contract.
DA Bridge Architecture
The DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge. The DA commitment consists of a data availability message provided as transaction input, made up of a byte array containing the signatures and all the addresses of the committee in ascending order. The sequencer distributes the data and collects signatures from Committee members offchain. Only the DA message is posted by the sequencer to the destination chain inbox (the DA bridge). A separate contract, the PolygonCommittee contract, is used to manage the committee members list and verify the signatures before accepting the DA commitment.
Funds can be lost if a malicious committee signs a data availability attestation for an unavailable transaction batch.
Funds can be lost if the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades.
No compression scheme yet.
The genesis state, whose corresponding root is accessible as Batch 0 root in the getRollupBatchNumToStateRoot(5,0) method of PolygonRollupManager, is available here.
The trusted sequencer request signatures from DAC members off-chain, and posts hashed batches with signatures to the WirexPayChainValidium contract.
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).
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.
The regular upgrade process for all system contracts (shared and L2-specific) starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 10d and then execute the upgrade. An upgrade of the Layer 2 specific rollup- or validium contract requires first adding a new rollupType through the Timelock and the RollupManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. The PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the PolygonRollupManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception. Furthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rolupTypes and manage operational parameters and fees in the PolygonRollupManager directly. The local admin of a specific Layer 2 can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.
Ethereum
Roles:
Permissioned to post new state roots and global exit roots accompanied by ZK proofs. Can also settle verified state roots without a timeout (‘consolidate pending state’).
Actors:
- A Multisig with 2 / 3 threshold.
- Can act on behalf of PolygonZkEVMTimelock if there is no emergency state, in which case there is no delay.
- Is allowed to interact with PolygonRollupManager - deploy new projects that use predefined rollup types (implementations) and connect them to the PolygonRollupManager.
- Is allowed to interact with PolygonRollupManager - manage all access control roles, add new rollup types (which are implementation contracts that can then be upgraded to by connected projects), update any connected projects to new rollup types and rollback batches, connect existing rollups to the PolygonRollupManager - acting via PolygonZkEVMTimelock with 10d delay if there is no emergency state, in which case there is no delay.
- Is allowed to interact with PolygonRollupManager - manage parameters like permissioned timeouts and fees for all connected projects, set the trusted aggregator, stop the emergency state, update projects and obsolete rollup types (implementations).
- Is allowed to interact with PolygonZkEVMTimelock - propose, cancel and execute transactions in the timelock, manage all access control roles - acting via PolygonZkEVMTimelock with 10d delay if there is no emergency state, in which case there is no delay.
- Is allowed to interact with PolygonZkEVMTimelock - propose, cancel and execute transactions in the timelock, manage all access control roles.
- Can upgrade the implementation of PolygonZkEVMBridgeV2, PolygonRollupManager, PolygonZkEVMGlobalExitRootV2 - acting via SharedProxyAdmin, PolygonZkEVMTimelock with 10d delay if there is no emergency state, in which case there is no delay.
Used in:
- A Multisig with 6 / 8 threshold.
- Is allowed to interact with PolygonRollupManager - activate the emergency state in the PolygonRollupManager and in the shared bridge immediately, effectively pausing all projects connected to them and making system contracts instantly upgradable.
Participants (8):
0xFe45…2e4b0xaF46…261D0xBDc2…FEFf0x4c16…88910x3ab9…D6220x49c1…0E860x9F7d…86A00x2188…1C28Used in:
- A Multisig with 3 / 8 threshold.
- Is allowed to interact with PolygonRollupManager - deploy new projects that use predefined rollup types (implementations) and connect them to the PolygonRollupManager.
Participants (8):
0x3038…D3b50xa439…AE310xD947…fCFC0xCE27…AaAc0x0B84…Ca770x0185…22A60x7316…44960xC8aa…39e9Used in:
- Is allowed to interact with PolygonDataCommittee - manage the members of the data availability committee and the threshold for valid commitments.
- Is allowed to interact with Validium - set core system parameters like the trusted sequencer and manage forced transactions/batches.
- Is allowed to interact with Validium - sole address that can force batches.
A Sequencer.
Can upgrade the implementation of PolygonDataCommittee - acting via ProxyAdmin.
A trusted Aggregator.
A trusted Aggregator.
Ethereum
Verifies ZK proofs for state roots of this Layer 2 via the PolygonRollupManager.
Implementation used in:
Manages the members of the data availability committee (DAC) and the threshold for accepting commitments from them (Currently 2/1).
Upgrade delay: No delay
The main system contract defining the prism Layer 2 logic. Entry point for sequencing batches. The source code of this contract is not verified on Etherscan.
Implementation used in:
Can be used to upgrade implementation of PolygonDataCommittee.
Can be used to upgrade implementation of PolygonZkEVMBridgeV2, PolygonRollupManager, PolygonZkEVMGlobalExitRootV2.
Implementation used in:
The central shared managing contract for Layer 2s on the Polygon AggLayer. This contract receives L2 state roots as well as ZK proofs. All connected Layer 2s can be globally paused by activating the ‘Emergency State’. This can be done by the PolygonSecurityCouncil or by anyone able to prove a non-deterministic pending state or after 1 week of inactive verifiers.
Upgrade delay: 10d
Proxy used in:
A merkle tree storage contract aggregating state roots of each participating Layer 2, thus creating a single global merkle root representing the global state of the AggLayer, the ‘global exit root’. The global exit root is synchronized to all connected Layer 2s to help with their interoperability.
Upgrade delay: 10d
Proxy used in:
- Can act on behalf of SharedProxyAdmin.
- Can act on behalf of PolygonZkEVMTimelock if there is no emergency state, in which case there is no delay.
- Can be used to interact with PolygonRollupManager - manage all access control roles, add new rollup types (which are implementation contracts that can then be upgraded to by connected projects), update any connected projects to new rollup types and rollback batches, connect existing rollups to the PolygonRollupManager.
- Can be used to interact with PolygonZkEVMTimelock - propose, cancel and execute transactions in the timelock, manage all access control roles.
- A timelock with access control. In the case of an activated emergency state in the PolygonRollupManager, all transactions through this timelock are immediately executable. The current minimum delay is 10d.
Implementation used in:
Value Secured is calculated based on these smart contracts and tokens:
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 unless upgrade is initiated by the PolygonSecurityCouncil in which case there is no delay.
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).