Frequently Asked Questions: Klever Ethereum Bridge

Education
1

IMG_9308
IMG_93081500Ă—785 143 KB

This section provides a comprehensive set of frequently asked questions and answers related to the Klever-Ethereum Bridge.

General Questions

1. What is the Klever-Ethereum Bridge?

The bridge is a decentralized cross-chain solution built on the Klever Virtual Machine (KVM) that connects the Klever Blockchain with the Ethereum network, enabling seamless token transfers between the two ecosystems.

2. Is the bridge decentralized?

Yes. Unlike centralized exchange services that require you to trust a third party, the bridge uses a multisig smart contract and a network of independent relayers. No single entity has total control over the bridge operations.

3. What is the role of a Relayer?

Relayers are nodes that act as a “mini-blockchain” specifically for cross-chain transactions. They monitor both chains, validate transaction data, and request the smart contracts to execute transfers. They do not handle your tokens directly; they only orchestrate the process.

Token Mechanics

4. What are “Wrapped Tokens”?

To move assets, the bridge uses Wrapped Tokens. Instead of moving a native token (like KLV or ETH), the native asset is locked in a contract on one chain, and a “Wrapped” version is minted on the destination chain.

  • On Klever: Wrapped versions are KDA tokens.

  • On Ethereum: Wrapped versions are ERC20 tokens.

5. Can I unwrap WrappedETH on the Klever Blockchain?

No. WrappedETH is not a native Klever token. To unwrap it, you must first bridge it back to an Ethereum account and perform the unwrapping there.

Fees and Transfers

6. Are there fees for using the bridge?

The fee structure depends on the direction of the transfer:

  • Klever to Ethereum: Part of the tokens will be deducted for transaction fees.

  • Ethereum to Klever: These transfers require no additional fees beyond the initial gas costs on the Ethereum side.

7. What happens if my transfer from Klever to Ethereum fails?

The system is designed to be secure. If a transaction fails for any reason, the KdaSafe contract will ensure that your assets are not lost.

8. How are tokens whitelisted?

The KDA-Safe contract (on Klever Blockchain) and the Safe contract (on Ethereum) each maintain their own whitelist of supported tokens. Token whitelisting is managed by an admin account that has permission to add and remove tokens from the whitelist.

Only whitelisted tokens can be bridged between networks. This whitelist mechanism provides an additional security layer by ensuring that only verified and approved tokens can utilize the bridge infrastructure.

Important: Token whitelisting does not require relayer consensus. However, it is a separate administrative function that uses multisig governance for enhanced security:

  • On Ethereum: Controlled by a governance smart contract with multisig requirements

  • On Klever Blockchain: Controlled by admin accounts using the account permission kapp (Klever’s native permission system) with multisig

This multisig requirement ensures that token whitelisting decisions require multiple authorized signatures, preventing unilateral control while remaining separate from the relayer network’s role in transfer validation.

Security and Technical Design

9. Why should I trust the Relayers?

The bridge uses a Proof of Stake (PoS) model similar to the Klever Blockchain validators. Relayers must stake KFI to participate. If a relayer misbehaves, their stake is “slashed,” providing a strong financial incentive to remain honest.

10. How do the relayers reach an agreement?

Relayers coordinate through a consensus mechanism to validate cross-chain transactions. Relayers (independent actors) must reach consensus to approve each transfer before execution. This quorum requirement ensures that no single relayer can control or manipulate the bridge.

When a transfer is initiated, relayers:

  • Monitor both blockchains for pending transactions

  • Validate the transaction details independently

  • Reach consensus by voting on the transfer’s validity

  • Execute the transfer through the Multisig contract once consensus is achieved

11. What is the technical stack of the bridge?

The bridge is open-source and consists of three main components:

  • Klever Contracts: Written in Rust.

  • Ethereum Contracts: Written in Solidity.

  • Relayer Service: Written in Go.

12. How does the multisig quorum protect assets during a transfer?

The multisig quorum protects assets during a transfer by ensuring that no single entity has control over the bridge, thereby removing a central point of failure. This protection is achieved through several decentralized security layers:

Consensus-Based Execution

The bridge is governed by a Multisig smart contract that acts as a controller for bridge operations. For a transfer to be executed, a quorum (consensus) among authorized relayer addresses must be reached. Only after the required number of relayers validate the transaction and agree on its validity will the multisig contract trigger the necessary calls to other contracts to release or mint the assets.

Separation of Assets and Authority

A key security feature is that the relayers themselves do not handle or transfer tokens directly. Instead:

  • Relayers function like a “mini-blockchain” whose sole purpose is to monitor the chains and validate transactions.

  • Smart Contracts (such as KDA-Safe on Klever or the Safe Contract on Ethereum) are the only entities that actually hold, lock, mint, or burn the assets.

  • The Multisig contract serves as the only authorized bridge between the relayer consensus and the actual movement of funds.

Economic Deterrents (Proof of Stake)

To ensure that relayers act honestly, the system utilizes a Proof of Stake mechanism.

  • Staking: Each relayer must stake a specific amount of KFI tokens to participate in the network.

  • Slashing: If a relayer misbehaves—for instance, by attempting to validate a fraudulent transaction—their staked KFI is “slashed,” meaning they lose a significant portion of their money as a penalty.

Authorized Access Control

The Multisig contract is programmed to only interact with a whitelist of authorized relayer addresses. This ensures that even if an outside attacker attempts to send a transfer request to the contract, it will be rejected because it did not originate from a recognized, staked member of the relayer quorum.

13. How do relayers use the Multi-Transfer-KDA helper contract?

Relayers use the Multi-Transfer-KDA helper contract primarily as the execution mechanism for transactions moving from Ethereum back to the Klever Blockchain. Because relayers do not handle or transfer tokens directly, they act as orchestrators that monitor the Ethereum network for processed transactions and then request the Klever smart contracts to deliver the assets.

Specifically, relayers utilize this helper contract to perform the following technical tasks:

  • Handling Multiple Assets: The contract allows relayers to manage the transfer of multiple KDA tokens simultaneously, streamlining the delivery of various assets in a single operation.

  • Interfacing with Wrappers: Relayers use the contract to interact with the bridged-token-wrapper when a specific transfer type necessitates wrapping or unwrapping tokens before they are delivered to the user.

  • Execution via Consensus: The relayer’s call to the Multi-Transfer-KDA contract is governed by the Multisig controller, which ensures that the transfer is only executed after a quorum of authorized relayers has reached consensus.

Once the relayers trigger this contract following a successful transaction on the Ethereum side, the assets are transferred directly to the user’s Klever account without the need for additional bridge fees.

14. What happens when a transfer fails on the Klever side?

When a transfer from Ethereum to Klever Blockchain fails for any reason, the system is designed with a safety mechanism to ensure that your assets are not lost.

Transfer Process (Ethereum → Klever):

  • Initial Locking: When you initiate a transfer from Ethereum, your ERC-20 tokens are locked in the Ethereum Safe smart contract

  • Relayer Validation: The relayer network monitors and validates the transaction on both blockchains

  • Minting on Klever: If validation is successful, equivalent wrapped KDA tokens are minted on Klever Blockchain

If the Transaction Fails on Klever:

  • Refund Transaction: A refund transaction will be executed on the Klever side

  • Token Release: The relayers will return the locked tokens from the Ethereum Safe smart contract back to your Ethereum account

  • Asset Protection: Your original ERC-20 tokens remain safe and are released back to you

Role of the Ethereum Safe Contract:

The Ethereum Safe contract manages this lifecycle, acting as the vault that holds the assets until the relayer network confirms whether the transaction succeeded or failed on the Klever side.

Relayer Monitoring:

The relayer network orchestrates this process by monitoring both blockchains independently. They validate the outcome and ensure the Ethereum Safe contract releases the locked tokens back to your account if the transfer fails on Klever.

Finality Protection:

  • Relayers wait for multiple block confirmations before processing transactions

  • This ensures transactions won’t be reverted due to chain reorganizations

  • Only after sufficient confirmations do relayers proceed with actions on the destination chain

15. How is the whitelist managed between Klever and Ethereum contracts?

The whitelist management between Klever and Ethereum contracts is an administrative function controlled by admin accounts using multisig governance mechanisms on each blockchain, not a consensus process involving the bridge relayer network.

Klever Blockchain Management

On the Klever side, the KDA-Safe contract maintains the whitelist of supported tokens. The admin account of the multisig uses Klever Blockchain’s native multisig mechanism to add or remove tokens from this whitelist. The KDA-Safe contract is also responsible for:

  • Locking and burning KDA tokens during transfers to Ethereum

  • Minting wrapped KDA tokens for incoming transfers from Ethereum

Ethereum Blockchain Management

On the Ethereum side, the Safe contract maintains the whitelist of supported tokens. The admin account uses a multisig governance contract on Ethereum to manage which tokens can be bridged. The Safe contract handles:

  • Locking ERC-20 tokens during transfers to Klever

  • Minting wrapped ERC-20 tokens for outgoing transfers from Klever

Multisig Governance vs. Relayer Consensus

It’s important to distinguish between two different types of multisig operations:

Token Whitelisting (Admin Multisig):

  • Managed by admin accounts using blockchain-native multisig governance

  • On Klever: Uses Klever Blockchain’s multisig mechanism

  • On Ethereum: Uses a multisig governance contract

  • Bridge relayers are NOT involved in this process

Transfer Validation (Relayer Multisig):

  • Managed by the bridge relayer network

  • Requires relayers (independent actors) for consensus approval each transfer

  • This is a separate process from token whitelisting

Security Layer

Only whitelisted tokens can be bridged between networks, providing an additional security layer to ensure only verified and approved tokens utilize the bridge infrastructure. The multisig governance requirement ensures that token whitelisting decisions require multiple authorized signatures, preventing unilateral control.

16. What happens if someone tries to whitelist a scam token?

Token whitelisting is managed by multisig wallet accounts on each blockchain, not by bridge relayers. The security against scam tokens comes from the multisig governance requirement.

How it works:

On Klever Blockchain, the admin account uses Klever’s native multisig mechanism. On Ethereum, the admin account uses a multisig governance contract. In both cases, all multisig participants must sign and validate a token before it can be whitelisted.

Protection layers:

  • Multisig Requirement: A single admin cannot add a token alone. If any multisig participant identifies a scam token, they can refuse to sign, blocking the whitelisting entirely.

  • Smart Contract Validation: The bridge has built-in protections against contracts impersonating ERC20 tokens, helping detect fraudulent implementations.

  • Manual Validation: Multisig participants validate tokens before signing to approve their addition to the whitelist.

Important: Relayers are not involved in token whitelisting. Their role is limited to monitoring and validating cross-chain transfers of already-whitelisted tokens. The staking and slashing mechanisms for relayers apply only to transfer validation misbehavior, not to whitelisting decisions.

17. How does the bridge handle large batch transactions during high traffic?

The bridge manages high traffic and large volumes of transactions through a combination of batch processing, specialized helper contracts, and a decentralized relayer network.

1. Batch Execution Mechanism

To handle high demand efficiently, the bridge uses a batching system to process multiple transactions together:

  • Ethereum Bridge Contract: Serves as the main interface for relayers to execute batches of cross-chain transactions at once, reducing the overhead of individual contract calls and optimizing gas costs

  • Multi-Transfer-KDA: On the Klever Blockchain, this helper contract handles the transfer of multiple KDA tokens simultaneously, allowing the bridge to deliver various assets to multiple users in a single streamlined operation

2. Relayer Coordination

The decentralized network of relayers coordinates to process these batches efficiently:

  • Consensus-Driven Validation: Before any batch is processed, relayers must reach consensus to validate the transactions

  • Independent Monitoring: Relayers monitor both blockchains independently for pending transactions

  • Batch Processing: Multiple transactions are grouped together before execution on the destination chain, improving efficiency during high-traffic periods

3. Performance Incentives

The bridge’s reliability during high-traffic periods is reinforced by economic incentives:

  • Transaction-Based Fees: Relayers earn fees from each transfer through the fee reserve mechanism, incentivizing them to process transactions efficiently

  • KFI Staking: Relayers must stake KFI tokens to participate in the validation process

  • Slashing Risk: Relayers face financial penalties (slashing) if they misbehave or fail to maintain the integrity of the transfer flow, creating strong economic incentives to ensure the bridge remains performant and secure

4. Asset Lifecycle Management

Even during high traffic, the bridge ensures asset safety through its token handling mechanisms. The bridge follows one of two mechanisms based on token permissions and native blockchain:

Lock and Release Mechanism:

  • Tokens are locked in the Safe contract on the source chain

  • Equivalent tokens are minted on the destination chain

  • If a transaction fails, locked tokens are released back to the user

Burn and Mint Mechanism:

  • Tokens are burned on the source chain when the transaction is processed

  • Equivalent tokens are minted on the destination chain

Important: A token cannot both lock and burn simultaneously. The mechanism used depends on the bridge’s permissions and the token’s native blockchain. Each transaction within a batch follows the appropriate mechanism to maintain supply balance across both chains.

Finality Protection:

  • Relayers wait for multiple block confirmations before processing transactions

  • This ensures transactions won’t be reverted due to chain reorganizations

  • Only after sufficient confirmations do relayers proceed with corresponding actions on the destination chain

18. How does batching help save on gas fees during transfers?

Batching helps save on gas fees by allowing the bridge to group multiple cross-chain transactions into a single execution, thereby spreading the fixed costs of a blockchain transaction across many users. Based on the sources, this efficiency is achieved through specific smart contracts designed for bulk operations.

Batching on the Ethereum Side

The Ethereum Bridge Contract serves as the primary interface for this optimization.

  • Execution of Groups: Instead of processing every transfer request individually—which would require paying a high base gas fee for every single transaction—relayers use this contract to execute batches of cross-chain transactions.

  • Reduced Overhead: By combining several transfers into one batch, the relayers minimize the number of interactions with the Ethereum blockchain, significantly reducing the cumulative gas required to finalize the transfers.

Batching on the Klever Blockchain Side

Similarly, the Klever side utilizes the Multi-Transfer-KDA helper contract.

  • Multiple Token Handling: This contract is specifically engineered to handle the transfer of multiple KDA tokens simultaneously.

  • Wrapped Asset Efficiency: It also interacts with the bridged-token-wrapper when wrapping or unwrapping is required for these multiple assets, ensuring that even complex token movements are handled in a consolidated manner.

Economic Impact for the User

The efficiency gained from batching is particularly important for Klever-to-Ethereum transfers because:

  • Fee Deduction: In this direction, a portion of the tokens being moved is deducted to cover transaction fees.

  • Optimization: By using relayers to batch these transactions via the Bridge Contract, the overall cost per user is lowered, potentially reducing the amount deducted from their transferred tokens.

Role of the Relayer Network

The relayer service (written in Go) is responsible for this orchestration. The relayers monitor both chains and, once they reach a quorum (consensus) through the Multisig contract, they trigger these batch executions. This ensures that the gas-saving batching process is both decentralized and secure.

19. Does the bridge support auto-refunds if Ethereum gas fees spike?

No, the bridge does not have an automatic refund system. Refunds are a manual process if a transaction fails.

However, users are protected from gas fee spikes because the bridge uses a fixed fee model. When transferring from Klever Blockchain to Ethereum, the fee charged to the user is predetermined and deducted upfront on the Klever side. If Ethereum gas fees spike during execution, the relayer absorbs the additional cost, not the user.

How Fee Protection Works

Fixed Fee Model:

  • Fees are deducted on the Klever side when initiating the transfer

  • A portion of the bridged amount is held in the safe smart contract as a fee reserve

  • This reserved amount is fixed regardless of actual gas costs on Ethereum

  • Result: Users pay a predictable fee; relayers take the loss if gas spikes

Fee Distribution:

  • Klever → Ethereum: Fixed fees deducted from the transfer amount

  • The reserved fees are distributed to relayers after transaction completion

  • Relayers handle Ethereum gas costs from their share of the fees

Transaction Safety Mechanism

Asset Protection During Transfer:

The bridge uses different mechanisms depending on token permissions and native blockchain:

For Native Klever Tokens → Ethereum:

  • Lock and Burn: Tokens are locked in the KdaSafe contract and then burned

  • Validation: Relayers reach consensus before executing on Ethereum

  • Minting on Ethereum: Wrapped ERC-20 tokens are minted on Ethereum

  • Batch Execution: Transaction is processed in batches for efficiency

For Native Ethereum Tokens → Klever:

  • Lock on Ethereum: ERC-20 tokens are locked in the Ethereum Safe contract

  • Validation: Relayers reach consensus before executing on Klever

  • Minting on Klever: Wrapped KDA tokens are minted on Klever Blockchain

  • Release (if needed): If transaction fails, locked tokens are released back

The bridge follows one of two mechanisms based on token permissions:

  • Lock and Release mechanism: Tokens are locked on source chain and released if needed

  • Burn and Mint mechanism: Tokens are burned on source chain and minted on destination

Important: A token cannot both lock and burn simultaneously. The mechanism used depends on the bridge’s permissions and the token’s native blockchain.

If a Transaction Fails:

  • Refund is a manual process, not automatic

  • Users must contact support or the bridge operators

  • The manual refund process ensures user funds aren’t permanently lost

  • Tokens locked on the source chain can be released back to the user

Finality Protection

The bridge implements finality protection through block confirmation waiting:

  • Relayers wait for multiple block confirmations after a transaction

  • This ensures the transaction won’t be reverted due to chain reorganizations

  • Only after sufficient confirmations do relayers proceed with corresponding actions

Batch Processing for Efficiency

To optimize gas costs on Ethereum, relayers use batch processing:

  • Multiple transactions are grouped into a single execution

  • This reduces per-transaction gas costs

  • Improves overall efficiency despite high Ethereum fees

20. How do KdaSafe and the Ethereum Safe contract coordinate supply?

The KDA-Safe and the Ethereum Safe contract coordinate token supply by acting as mirrored vaults that manage the lifecycle of tokens through synchronized locking, minting, burning, and releasing mechanisms.

Their coordination is governed by the following technical processes:

1. Mirrored Supply Logic

To ensure the total supply of a token remains constant across both ecosystems, the contracts use a reciprocal relationship based on the token’s native blockchain.

Default Flow (Ethereum → Klever):

Since currently whitelisted tokens are native to Ethereum, the typical flow is:

  • Lock on Ethereum: Native ERC-20 tokens are locked in the Ethereum Safe contract

  • Mint on Klever: Equivalent wrapped KDA tokens are minted on Klever Blockchain

Reverse Flow (Klever → Ethereum):

  • Lock/Burn on Klever: KDA tokens are locked and burned in the KDA-Safe contract

  • Mint on Ethereum: Equivalent wrapped ERC-20 tokens are minted on Ethereum

The specific mechanism (Lock/Mint vs Burn/Release) depends on which blockchain the token is native to, ensuring the total supply across both chains remains balanced.

2. The Role of Relayer Consensus

These two contracts do not communicate directly; instead, they are coordinated by a decentralized network of relayers.

  • Monitoring: Relayers monitor both contracts for specific events (like lock requests)

  • Validation: Relayers validate the transactions independently on each chain

  • Consensus-Based Execution: Once a quorum of relayers reaches consensus that a supply-changing event has occurred on one chain, they execute the corresponding action on the destination chain

  • Final Action: The relayers instruct the respective Safe contract (KDA-Safe or Ethereum Safe) to perform the corresponding mint, burn, lock, or release operation

3. Supply Integrity via Whitelisting

Both contracts manage a whitelist of supported tokens to prevent unauthorized assets from affecting the bridge’s supply balance.

  • KDA-Safe: Maintains the whitelist on Klever Blockchain (managed by admin multisig)

  • Ethereum Safe: Maintains the whitelist on Ethereum (managed by admin multisig)

  • Purpose: Only verified tokens can be bridged, protecting the economic integrity of the assets

Token whitelisting is an administrative function controlled by multisig wallet accounts, separate from the relayer network’s role in transfer validation.

4. Safety and Finality Protection

To prevent supply imbalances due to failed or reverted transactions, the bridge implements finality protection:

Block Confirmation Waiting:

  • Relayers wait for multiple block confirmations after a transaction before processing it

  • This ensures the transaction won’t be reverted due to chain reorganizations

  • Only after sufficient confirmations do relayers proceed with the corresponding action on the destination chain

Supply Balance Guarantee:

  • Tokens are only minted/released on the destination chain after source chain finality is confirmed

  • If a transaction fails or is not confirmed, no corresponding action occurs on the destination chain

  • This ensures the total supply remains balanced across both chains even in edge cases

1 Like