Search for projects by name
LightLink is a project that lets dApps and enterprises offer users instant, gasless transactions.
LightLink is a project that lets dApps and enterprises offer users instant, gasless transactions.
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 proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
2024 Apr 08 — 2025 Apr 08
2024 Apr 08 — 2025 Apr 07
Currently the system permits invalid state roots. More details in project overview.
Proof construction and state derivation fully rely on data that is posted on Celestia. Sequencer tx roots are not checked against the Blobstream bridge data roots onchain, but L2 nodes can verify data availability by running a Celestia light client.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
The project implements an incomplete and non-funcional proof system.
LightLink chain state roots are periodically posted to Ethereum through a CanonicalStateChain contract on L1 as block headers that also contain Celestia data pointers. After the challenge window of 5d, the published state root is assumed to be correct. During the challenge window, anyone can challenge a block header against some basic validity checks. The challenge fee required is 1.5 ETH. Once challenged, the permissioned defender can respond within 2d to the challenge, by providing the L2 header and the previous L2 header. If the defender does not respond, the block header is considered invalid, the canonical state chain is rolled back to the previous state root, and the challenger can claim back the challenge fee. If the defender successfully responds, the challenger loses the challenge fee to the defender. Since only the block header can be challenged and not the state transition, the system is vulnerable to invalid state roots. Moreover, state roots are not used for ERC20 withdrawals from the LightLinkERC20Bridge. Users can deposit tokens on the LightLink chain by sending them to the L1BridgeRegistry contract on Ethereum L1. On the LightLink chain, ERC20 token minting is then authorized by a permissioned set of signers providing signatures as input to the syncDeposit() function on the L2ERC20Predicate contract. Users can withdraw their funds by submitting a withdraw() transaction to the L2ERC20Predicate contract, which will burn the tokens on the LightLink chain. To then unlock tokens from the bridge on L1, a validator multisig needs to validate the withdrawal based on off-chain validity checks. Users can exit the network once enough validators have signed off on the withdrawal. Currently, a minimum of 2 validators is required to sign off on a withdrawal. To deposit the gas token, i.e. ETH, the LightLinkPortal is used which uses the CanonicalStateChain as the source for the state root, and withdrawals follow the usual OP stack process.
Users can be censored if validators decide to not mint tokens after observing an event on Ethereum.
Funds can be stolen if validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum.
Funds can be stolen if validators relay a withdraw request that wasn't originated on the source chain.
Funds can be stolen if the publisher posts an invalid block header on Ethereum.
Is allowed to interact with CanonicalStateChain - it can publish new block headers, which both includes pointers to Celestia DA and the state root for withdrawals, meaning that sequencing and state updates are not decoupled.
Sends messages from host chain to this chain, and relays messages back onto host chain. In the event that a message sent from host chain to this chain is rejected for exceeding this chain’s epoch gas limit, it can be resubmitted via this contract’s replay function.
The main entry point to deposit ERC20 tokens from host chain to this chain.
The L1BridgeRegistry contract is used to store the address of the LightLink multisig and the address and voting power of the validators managing the bridge.
ERC20 token escrow contract. It is validated by external validators, according to the L1BridgeRegistry values. This contract can store any token.
Fork of the OP stack’s SystemConfig. It link to the main portal contract and stores a ‘start block’ number. Both values are currently unused. Most importantly, it does NOT contain the resource configuration info.