Solbridge: Validators Continued

In this entry, we would like to discuss the process of signature validation. As mentioned before, Validators always keep track of bridge smart contracts logs, on the lookout for new transactions. When a transaction is detected, it has to go through the signature validating process. Let us explain it with a simple example.

Assume that validator tracks Blockchain A (source blockchain) and detects a new transaction request. It verifies the transaction and sends its signature to the bridge if the transaction is correct. When the transaction gathers enough signatures, the User sends a single signature of the first Validator who approved the transaction or signatures from 2/3 of Validators to the Blockchain B (destination blockchain).

Blockchain B then checks whether the Validators signed the transaction. If there is a signature from the Validator that is not supposed to validate the transaction (for example, Validator that validates Blockchain C), Blockchain B’s smart contract does not allow money minting.

In most of the bridges, to notify the receiving blockchain about transaction confirmation, the user is supposed to send 2/3+ of signatures to the receiving blockchain. However, a transaction such as this is quite heavy on data and demands a large fee. Solbridge’s solution introduces the idea of a cheap single-signature transaction, providing the same level of security.

When sending a transaction to the receiving blockchain, it is up to the User to decide whether to send a fast, yet expensive transaction; or a cheap one, placing minted tokens under a 5-minute lock-in period.

In the case of a cheap transaction, the user has to wait for signatures from 2/3 of Validators. However, only 1 of the signatures has to be sent from any Validator who confirmed the transaction.

After the transaction is sent to the receiving blockchain, the wrapped tokens are minted but remain locked. If there are no cancellations from Validators during the 5-minute interval, the minted tokens are unlocked on the user’s address. This lock-in period ensures that even if a malicious user sends 1 signature before 2/3 of Validators confirm the transaction, there is enough time for Validators to cancel it.

When an incorrect transaction is detected by the Validator, it verifies whether ⅔ of other Validators confirmed it. If they did, the Validator does nothing. If they didn’t, the Validator sends a cancellation transaction to the receiving blockchain. The cancellation transaction burns tokens on the receiving blockchain, essentially cancelling the transfer.




APYSwap Foundation is established to inspire and support new projects using the APYSwap ecosystem.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Top 5 smart contract platforms

Enabling limitless scalability for Web3

Annual Review of Morpheus Labs 2020 (Year-end Roundup)

Lambda FAQ (Ver 4.0)

Apes vs. Whales: Origin Story

Improve Your Customers’ Banking Experience with Digital Asset Banking Solution

E1337 Whitepaper: Version 1.0 Lite

Separating the man from the boys: Ethereum

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


APYSwap Foundation is established to inspire and support new projects using the APYSwap ecosystem.

More from Medium

Bohd Finance: Quick tutorial for lending and borrowing assets on Boba Network

KEEZ DAO | Lite Paper V1.0 1/5/22

Announcement: Liquidity Pool Compensation Plan for Cosmic Token MOX

DeFi + derivatives + DEX = ζ