This security review of bridging was conducted to guide decisions around KSX bridging solutions. It was written during my investigation into various different bridging protocols and serves as an explainer for the architecture and design of each.

Token bridges are simply a set of smart contracts on source and destination chains with an intermediary custodian. The custodian locks tokens on the source network and releases them on the destination network. In practice, the custodian is typically a decentralized network of validators, and tokens are burnt on the source chain and minted on the destination chain. The reversibility of this process makes these newly minted assets 1:1 with their original source asset.

The problem with the bridging protocols is that the technology is relatively simple and has become quite commoditized — leaving competitors to differentiate via marketing. Unfortunately, layering bridge solutions in a blanket of buzzwords and jargon complicates the process of comparing different bridges. Risks are magnified when bridging can be vulnerable to exploits in the billions. In hope, of clarifying different bridging vendors for KSX, below is a write up on a few of the most popular bridging protocols.

Bridging involves a trusted entity transferring funds from one chain to another. However, this trust in a centralized entity can lead to a rug pull situation when the value of secured funds surpasses the cost of performing a malicious act. This trusted entity also has to ensure the bridge's security for its entire lifespan, which could potentially be indefinite. If they fail to do so, the token risks becoming unbacked if an exploit occurs. Nowadays, most bridges are no longer centralized.

In 2023, the well-known Multichain bridge experienced several days of downtime, leaving funds stranded in transit between chains. The founder of Multichain had disappeared, taking with him the private keys to the MPC that secured the bridge. Consequently, the team could not access the centralized servers, which were owned by the founder and contained the MPC keys.

MPC is a secure, recognized cryptographic mechanism for distributing control of a private key. However, storing MPC keys in a single location undermines the very purpose of MPC - a technology meant to decentralize control. It's crucial to remember that the use of a certain technology does not automatically ensure its proper implementation. With this in mind, we will review the bridge technologies below.

Starting with Stargate, it is currently the most used bridge according to DefiLlama. It's powered by the LayerZero cross-chain communication network. LayerZero itself is immutable. However, the network is composed of mutable DVNs (Decentralized Validator Networks). These DVNs run offchain, are siloed from each other, and are operated by various different actors. It's up to app implementers to choose how many DVNs are required to verify a cross-chain message. LayerZero operates some default DVNs to guarantee that there will always be at least one trusted DVN to secure the network (assuming LayerZero the entity continues to exist). However, enabling anyone to operate a DVN ensures the network is a permissionless, decentralized network. Similarly, LayerZero takes the same approach for the executors, which relay approved actions from the DVNs to the destination chain.

As of today, Stargate has not had any notable public incidents.

If measured in terms of permissionless-ness and decentralization of the bridge architecture, Stargate and subsequently LayerZero would be most secure. However, a lot of the configuration is pushed to the end user, leaving the application developer responsible for certain levels of security.

Transporter, a newcomer in the world of bridging, is built upon the highly secure and robust CCIP architecture. Despite being new, it falls back on Chainlink, one of the longest standing providers of critical blockchain infrastructure. Chainlink has created a security ranking for bridges and Transporter falls under their highest category, Level-5. This is because Transporter uses multiple Decentralized Oracle Networks (DONs) to secure the bridge.

One of these DONs is a Risk Monitoring Network. This network, built from scratch with an independent programming stack, verifies that the other two networks are functioning correctly. If a bridging lane is found to be malfunctioning, it will be paused, prioritizing security over liveness.

In a perfect scenario, several decentralized networks would theoretically provide optimal security. However, after discussions with Chainlink, the extent of decentralization and distribution among the Risk DON validators remains unclear. The documentation also fails to clarify the process of becoming a validator, insinuating it's not permissionless.

Chainlink is a well-recognized brand in terms of security. Their Transporter product is relatively new and hasn't yet faced a security incident. Only time will determine if the bridge can securely transport millions of dollars. However, even at its inception, Chainlink Transporter already boasts a higher security level than many other bridges.

Across utilizes an intent-based system for sending tokens across different chains. Users express their intent by depositing into the Across pool contract on the source chain. This triggers an event from the pool contract, which alerts relayers that an order needs to be filled on the destination chain. The funds stay in escrow on the source chain until the order is filled on the destination chain. This intent-based system allows Across to provide the fastest-to-finality bridging experience, as relayers bear the risk of optimistically filling orders.

Dataworkers serve as intermediaries in the system, helping to return funds to relayers once an order is fulfilled. A dataworker operates offchain, and its decentralization level remains unclear. According to Across documentation, there is a whitelist of approved dataworkers and a process for disputing dataworkers who submit invalid bundles. However, there is no additional information on this issue. Moreover, no governance proposal was found regarding the addition or removal of approved dataworkers.

While Across may require more trust assumptions, the bridge has not experienced any high-profile exploit incidents.

deBridge is a cross-chain messaging service and a bridge. New assets can easily be onboarded onto deBridge using dePort. deBridge is secured by an offchain network of validators that monitor for new bridge requests and sign off on each one, pushing the signature to Arweave for further processing. Any keeper can collect signatures from Arweave and submit these to the destination chain for execution. To ensure there is a sufficient incentive for a keeper/claimer to relay the transaction, an execution fee can be specified. In the worst-case scenario, a user can manually complete the bridging process.

deBridge is one of the simpler architectures for bridging assets. It is primarily secured by contracts on source/destination chains and a decentralized validator network. The succinct architecture is appealing, but it raises questions about the security of the decentralized validator network. Validators are required to post a bond of their own or attract stakers to delegate collateral towards the bond. The bond is composed of either ETH, USDT, or USDC. The validator network is protected by slashing of validators that act erroneously via governance. The bond is then used to compensate users who may have suffered financial loss.

There have not been any exploits of deBridge. However, there was an attempted email phishing campaign against deBridge employees by Lazarus. The attack was unsuccessful.

Celer is already used by Kwenta to bridge the token to Arbitrum and Base from Optimism. The integration has been successful so far; however, let's review its security again.

Celer's cBridge is built upon celerIM, their in-house cross-chain messaging infrastructure. celerIM is protected by validators or the "State Guardian Network". Any message across chains requires 2/3 of validators to respond successfully. The network piggybacks off the Cosmos consensus, and validators can be slashed if they misbehave. This is very similar to the deBridge architecture; however, staking is of the native token CELR and not deeper liquidity assets like ETH. It's also not clear who has the power to slash misbehaving validators.

The difference with Celer is that they offer an additional mechanism on top of SGN cross-chain messaging that provides fewer trust assumptions and higher security at the cost of a higher time delay -- a two-phase commit pattern. This introduces a quarantine (or timelock) period for cross-chain transfers and requires a third party (typically a dApp Operator) to run App Guardian to validate and finally commit the change to the chain. This feature is already running in production for higher-value transfers; however, it is not currently enabled for the KWENTA token.

To date, Celer has not had any major exploits; however, there was a frontend DNS hijacking incident back in 2022 that resulted in a total loss of $235k.

Wormhole is a well-known cross-chain messaging service with its roots in Solana. Portal is the new cross-chain token bridge built upon Wormhole architecture.

On-chain, Wormhole Core Contracts act as entry/exit points for cross-chain communication. Similarly to both Celer and deBridge, Wormhole uses an offchain validator "Guardian" network to process cross-chain messages. The Guardian network is composed of 19 validators that are not anonymous, but large, well-known validating companies in DeFi. They risk reputational damage by acting against the Wormhole Guardian network, however, slashing is not live at this time. Using t-schnorr signatures, each Guardian is responsible for signing their portion of the multisig. Once a cross-chain message is fully signed, this is batched together by the Spy daemon (a process that monitors for these events) into VAA, Verifiable Action Approvals. A VAA is just a fancy attestation or signed message that can be relayed to the destination chain for final execution.

Wormhole supports three tiers of relayers which aid in the decentralization of the relayer network. Standard relayers are decentralized on-chain relayer contracts that can receive a message from the Wormhole network and execute a transaction. Specialized relayers are offchain transaction relayers that can do a host of offchain processing before executing a relayed message on-chain. These are typically run by end-user operators or dApps. Lastly, client-side relayers are relayers that exist in frontends or wallet integrations and can relay on behalf of the user, but require the browser to remain open, for example. Users will also have to self-fund these relayed executions.

In 2022, Wormhole experienced an exploit of $320m where an unauthorized weETH mint occurred on Solana, enabling the exploiter to reverse bridge these newly minted tokens for locked wETH on Ethereum, draining the bridge. After unsuccessfully asking for funds back in return for a sizable bounty, Jump Trading, previously Wormhole's parent company, stepped in with its own funds to re-back the wETH on Solana.

Currently, the two leading standards for cross-chain bridging compatibility are xERC20 and LayerZero's OFT. Both facilitate the interoperability of a token across chains and enforce specific operations for burning and minting. It's not necessary for a token to follow these standards for cross-chain bridging; however, it streamlines and potentially reduces bridge/chain risk.

OFT (Omnichain Fungible Token) is a standard created by LayerZero that allows tokens to be burned and minted across chains, ensuring that supply remains constant across chains. The major benefit of OFT is that it's chain-agnostic, meaning that it can be used outside of EVM chains (for example, Solana). There is no requirement that an OFT-based token has to be used with LayerZero, however, LayerZero is built to support the standard, and there are no other bridges that support OFT.

xERC20 is a proposed EIP to coalesce all bridging solutions around a singular standard and prevent vendor lock. It was championed by Connext, but with the intent that it would be an interoperable standard all bridges would follow. xERC20 enables the original token issuers to have a "canonical" bridged token that is not controlled by the bridge, but by the original token issuer. The controller can decide things like which bridges have mint/burn ability and rate limits for certain bridges. This is an EVM specific standard. The standard is still in draft form, and most bridges (other than Connext) still follow their own proprietary solutions.

KSX does not need to adopt any of these standards as bridging can still be done via traditional "Lock and Mint" mechanisms, however, if a clean standard is desired, the time to implement this is during token development.

If one bridge stands out in terms of security, it would likely be Stargate due to its commitment to decentralization. If the LayerZero Labs organization were to dissolve, it is probable that LayerZero's cross-chain infrastructure would continue to operate. While shifting responsibilities to end-user operators increases the technical complexity of building solutions, it is a necessary trade-off to reduce trust assumptions and enable truly permissionless cross-chain communication.

However, the reality is that most modern bridging solutions are quite secure. The industry has learned from the failures of earlier bridges like Ronin, Nomad, and Multichain, and has evolved to better leverage decentralization for cross-chain security. Any bridge, particularly the ones mentioned above, that utilizes a type of decentralized validator network is sufficient for bridging KSX.

This security review of bridging was conducted to guide decisions around KSX bridging solutions. It was written during my investigation into various different bridging protocols and serves as an explainer for the architecture and design of each.

Token bridges are simply a set of smart contracts on source and destination chains with an intermediary custodian. The custodian locks tokens on the source network and releases them on the destination network. In practice, the custodian is typically a decentralized network of validators, and tokens are burnt on the source chain and minted on the destination chain. The reversibility of this process makes these newly minted assets 1:1 with their original source asset.

The problem with the bridging protocols is that the technology is relatively simple and has become quite commoditized — leaving competitors to differentiate via marketing. Unfortunately, layering bridge solutions in a blanket of buzzwords and jargon complicates the process of comparing different bridges. Risks are magnified when bridging can be vulnerable to exploits in the billions. In hope, of clarifying different bridging vendors for KSX, below is a write up on a few of the most popular bridging protocols.

Bridging involves a trusted entity transferring funds from one chain to another. However, this trust in a centralized entity can lead to a rug pull situation when the value of secured funds surpasses the cost of performing a malicious act. This trusted entity also has to ensure the bridge's security for its entire lifespan, which could potentially be indefinite. If they fail to do so, the token risks becoming unbacked if an exploit occurs. Nowadays, most bridges are no longer centralized.

In 2023, the well-known Multichain bridge experienced several days of downtime, leaving funds stranded in transit between chains. The founder of Multichain had disappeared, taking with him the private keys to the MPC that secured the bridge. Consequently, the team could not access the centralized servers, which were owned by the founder and contained the MPC keys.

MPC is a secure, recognized cryptographic mechanism for distributing control of a private key. However, storing MPC keys in a single location undermines the very purpose of MPC - a technology meant to decentralize control. It's crucial to remember that the use of a certain technology does not automatically ensure its proper implementation. With this in mind, we will review the bridge technologies below.

Starting with Stargate, it is currently the most used bridge according to DefiLlama. It's powered by the LayerZero cross-chain communication network. LayerZero itself is immutable. However, the network is composed of mutable DVNs (Decentralized Validator Networks). These DVNs run offchain, are siloed from each other, and are operated by various different actors. It's up to app implementers to choose how many DVNs are required to verify a cross-chain message. LayerZero operates some default DVNs to guarantee that there will always be at least one trusted DVN to secure the network (assuming LayerZero the entity continues to exist). However, enabling anyone to operate a DVN ensures the network is a permissionless, decentralized network. Similarly, LayerZero takes the same approach for the executors, which relay approved actions from the DVNs to the destination chain.

As of today, Stargate has not had any notable public incidents.

If measured in terms of permissionless-ness and decentralization of the bridge architecture, Stargate and subsequently LayerZero would be most secure. However, a lot of the configuration is pushed to the end user, leaving the application developer responsible for certain levels of security.

Transporter, a newcomer in the world of bridging, is built upon the highly secure and robust CCIP architecture. Despite being new, it falls back on Chainlink, one of the longest standing providers of critical blockchain infrastructure. Chainlink has created a security ranking for bridges and Transporter falls under their highest category, Level-5. This is because Transporter uses multiple Decentralized Oracle Networks (DONs) to secure the bridge.

One of these DONs is a Risk Monitoring Network. This network, built from scratch with an independent programming stack, verifies that the other two networks are functioning correctly. If a bridging lane is found to be malfunctioning, it will be paused, prioritizing security over liveness.

In a perfect scenario, several decentralized networks would theoretically provide optimal security. However, after discussions with Chainlink, the extent of decentralization and distribution among the Risk DON validators remains unclear. The documentation also fails to clarify the process of becoming a validator, insinuating it's not permissionless.

Chainlink is a well-recognized brand in terms of security. Their Transporter product is relatively new and hasn't yet faced a security incident. Only time will determine if the bridge can securely transport millions of dollars. However, even at its inception, Chainlink Transporter already boasts a higher security level than many other bridges.

Across utilizes an intent-based system for sending tokens across different chains. Users express their intent by depositing into the Across pool contract on the source chain. This triggers an event from the pool contract, which alerts relayers that an order needs to be filled on the destination chain. The funds stay in escrow on the source chain until the order is filled on the destination chain. This intent-based system allows Across to provide the fastest-to-finality bridging experience, as relayers bear the risk of optimistically filling orders.

Dataworkers serve as intermediaries in the system, helping to return funds to relayers once an order is fulfilled. A dataworker operates offchain, and its decentralization level remains unclear. According to Across documentation, there is a whitelist of approved dataworkers and a process for disputing dataworkers who submit invalid bundles. However, there is no additional information on this issue. Moreover, no governance proposal was found regarding the addition or removal of approved dataworkers.

While Across may require more trust assumptions, the bridge has not experienced any high-profile exploit incidents.

deBridge is a cross-chain messaging service and a bridge. New assets can easily be onboarded onto deBridge using dePort. deBridge is secured by an offchain network of validators that monitor for new bridge requests and sign off on each one, pushing the signature to Arweave for further processing. Any keeper can collect signatures from Arweave and submit these to the destination chain for execution. To ensure there is a sufficient incentive for a keeper/claimer to relay the transaction, an execution fee can be specified. In the worst-case scenario, a user can manually complete the bridging process.

deBridge is one of the simpler architectures for bridging assets. It is primarily secured by contracts on source/destination chains and a decentralized validator network. The succinct architecture is appealing, but it raises questions about the security of the decentralized validator network. Validators are required to post a bond of their own or attract stakers to delegate collateral towards the bond. The bond is composed of either ETH, USDT, or USDC. The validator network is protected by slashing of validators that act erroneously via governance. The bond is then used to compensate users who may have suffered financial loss.

There have not been any exploits of deBridge. However, there was an attempted email phishing campaign against deBridge employees by Lazarus. The attack was unsuccessful.

Celer is already used by Kwenta to bridge the token to Arbitrum and Base from Optimism. The integration has been successful so far; however, let's review its security again.

Celer's cBridge is built upon celerIM, their in-house cross-chain messaging infrastructure. celerIM is protected by validators or the "State Guardian Network". Any message across chains requires 2/3 of validators to respond successfully. The network piggybacks off the Cosmos consensus, and validators can be slashed if they misbehave. This is very similar to the deBridge architecture; however, staking is of the native token CELR and not deeper liquidity assets like ETH. It's also not clear who has the power to slash misbehaving validators.

The difference with Celer is that they offer an additional mechanism on top of SGN cross-chain messaging that provides fewer trust assumptions and higher security at the cost of a higher time delay -- a two-phase commit pattern. This introduces a quarantine (or timelock) period for cross-chain transfers and requires a third party (typically a dApp Operator) to run App Guardian to validate and finally commit the change to the chain. This feature is already running in production for higher-value transfers; however, it is not currently enabled for the KWENTA token.

To date, Celer has not had any major exploits; however, there was a frontend DNS hijacking incident back in 2022 that resulted in a total loss of $235k.

Wormhole is a well-known cross-chain messaging service with its roots in Solana. Portal is the new cross-chain token bridge built upon Wormhole architecture.

On-chain, Wormhole Core Contracts act as entry/exit points for cross-chain communication. Similarly to both Celer and deBridge, Wormhole uses an offchain validator "Guardian" network to process cross-chain messages. The Guardian network is composed of 19 validators that are not anonymous, but large, well-known validating companies in DeFi. They risk reputational damage by acting against the Wormhole Guardian network, however, slashing is not live at this time. Using t-schnorr signatures, each Guardian is responsible for signing their portion of the multisig. Once a cross-chain message is fully signed, this is batched together by the Spy daemon (a process that monitors for these events) into VAA, Verifiable Action Approvals. A VAA is just a fancy attestation or signed message that can be relayed to the destination chain for final execution.

Wormhole supports three tiers of relayers which aid in the decentralization of the relayer network. Standard relayers are decentralized on-chain relayer contracts that can receive a message from the Wormhole network and execute a transaction. Specialized relayers are offchain transaction relayers that can do a host of offchain processing before executing a relayed message on-chain. These are typically run by end-user operators or dApps. Lastly, client-side relayers are relayers that exist in frontends or wallet integrations and can relay on behalf of the user, but require the browser to remain open, for example. Users will also have to self-fund these relayed executions.

In 2022, Wormhole experienced an exploit of $320m where an unauthorized weETH mint occurred on Solana, enabling the exploiter to reverse bridge these newly minted tokens for locked wETH on Ethereum, draining the bridge. After unsuccessfully asking for funds back in return for a sizable bounty, Jump Trading, previously Wormhole's parent company, stepped in with its own funds to re-back the wETH on Solana.

Currently, the two leading standards for cross-chain bridging compatibility are xERC20 and LayerZero's OFT. Both facilitate the interoperability of a token across chains and enforce specific operations for burning and minting. It's not necessary for a token to follow these standards for cross-chain bridging; however, it streamlines and potentially reduces bridge/chain risk.

OFT (Omnichain Fungible Token) is a standard created by LayerZero that allows tokens to be burned and minted across chains, ensuring that supply remains constant across chains. The major benefit of OFT is that it's chain-agnostic, meaning that it can be used outside of EVM chains (for example, Solana). There is no requirement that an OFT-based token has to be used with LayerZero, however, LayerZero is built to support the standard, and there are no other bridges that support OFT.

xERC20 is a proposed EIP to coalesce all bridging solutions around a singular standard and prevent vendor lock. It was championed by Connext, but with the intent that it would be an interoperable standard all bridges would follow. xERC20 enables the original token issuers to have a "canonical" bridged token that is not controlled by the bridge, but by the original token issuer. The controller can decide things like which bridges have mint/burn ability and rate limits for certain bridges. This is an EVM specific standard. The standard is still in draft form, and most bridges (other than Connext) still follow their own proprietary solutions.

KSX does not need to adopt any of these standards as bridging can still be done via traditional "Lock and Mint" mechanisms, however, if a clean standard is desired, the time to implement this is during token development.

If one bridge stands out in terms of security, it would likely be Stargate due to its commitment to decentralization. If the LayerZero Labs organization were to dissolve, it is probable that LayerZero's cross-chain infrastructure would continue to operate. While shifting responsibilities to end-user operators increases the technical complexity of building solutions, it is a necessary trade-off to reduce trust assumptions and enable truly permissionless cross-chain communication.

However, the reality is that most modern bridging solutions are quite secure. The industry has learned from the failures of earlier bridges like Ronin, Nomad, and Multichain, and has evolved to better leverage decentralization for cross-chain security. Any bridge, particularly the ones mentioned above, that utilizes a type of decentralized validator network is sufficient for bridging KSX.