Understanding Wormhole
A bridge linking siloed blockchains
"For walls serve not only to keep the enemy out, but also to keep our brothers in." - Rumi, Persian poet
On a plane level, blockchain are fully independent in itself. They usually can't interact with the off-chain world or other blockchains. They are islands unto themselves.
This independency in itself, is a fundamental blockchain property.
Each blockchain is self-contained. It has its own rules and history of transactions, and it doesn't rely on any other system to function. If one blockchain has a problem, it won't affect others.
This feature is great on some dimensions but comes at a price, as liquidity and users are fragmented across chains.
This means crypto assets, identity, and liquidity are soiled to certain chains. It makes navigating these multiple chains (each with its wallets, tools, and protocols) quite annoying and time-consuming.
But what if these fragments can be leveraged as a combined potential?
Out of many, one
In my sub-title, I wrote "A bridge linking siloed blockchains".
In context, "siloed" refers to the isolation or lack of connectivity between different blockchain ecosystems, each operating independently with its own set of rules, protocols, and native assets.
The term "bridge" signifies a connection or interface that facilitates the transfer of assets, data, or transactions between these siloed blockchains.
The most common type of bridge is the Cross-chain bridge.
Simply put, a cross-chain bridge is a (virtual) link that allows messages to be sent between two blockchains. Any bit sequence can be used as the message (e.g., moving an NFT or token from Chain A to Chain B).
Assuming you wish to move a Bitcoin from Ethereum to Solana, you will need to perform the following two steps:
Take a bitcoin out of an Ethereum source account.
Transfer a bitcoin to a designated Solana account.
But since there is no way to touch both chains in a single transaction due to their lack of direct communication, you need a man-in-the-middle who has bitcoins on both chains and can assist you in the next two steps:
Transfer a bitcoin to their Ethereum account from your source account.
Transfer a bitcoin (or its equivalent) from your target's Solana account to yours
So, Cross-chain bridge = Middleman.
But there are a few difficulties with this arrangement…
How can a bridge make sure that these two actions take place in unison—that is, either both succeed or both fail? You or the bridge will lose money if one of them succeeds while the other fails.
How can a bridge make sure that the identical message is sent to the target account and not to any other account—that is, only one bitcoin, not one Dogecoin, not one other coin, or two bitcoins—and to your target account?
How can a bridge guarantee that a message is sent exactly once (for example, their Solana account would never transmit twice to your target account)?
What answers these questions?
Wormhole
Wormholes are like tunnels in spacetime that could connect very distant regions of space or even different universes - John Wheeler
Somewhere, something incredible is waiting to be known - Carl Sagan
Wormhole is exactly as its name sounds. It is blockchain’s very own Einstein-Rosen bridge. It is a cross-chain message-passing protocol.
Initially, Wormhole was designed as a cross-chain token wrapping and swapping protocol between Solana and Ethereum.
Since this original design and implementation, Wormhole has expanded to become a cross-chain messaging layer, which not only allows token wrapping and swapping between chains but also enables external protocols to build on top of it by leveraging Wormhole’s cross-chain state attestation model and messaging.
As a cross-chain messaging protocol, Wormhole Messaging serves as a foundational infrastructure that developers can build on top of. It is open-sourced also.
Messaging provides the basic language and framework to send data securely between two systems that aren’t compatible. The core Wormhole bridge operates by running smart contracts on both the Source Chain (where the data currently resides) and the Target Chain (where the data will be moved).
At the same time, protocols on top can fulfil other use cases, such as token bridges (e.g. Portal, Allbridge), cross-chain DEXs (e.g. Mayan Swap, Hashflow), and money markets (e.g. Pike, Synonym).
Wormhole’s Architecture
Wormhole doesn't stop at just token transfer. It extends its capabilities to support the transfer of unique digital assets like NFTs and DAOs.
But how does Wormhole achieve this?
Wormhole's architecture comprises both on-chain and off-chain components that work together to enable secure and efficient cross-chain communication.
On-Chain Components
The on-chain components start with the Emitter contract that interacts with the Wormhole Core Contract to publish a message. This action results in an Event recorded in the Transaction Logs, providing details about the emitter and sequence number to identify the message.
Several contracts can serve as Emitters, including:
xAsset Contracts for asset conversion and bridging
Relay Contracts for message dispatch across chains
Worm Router Contracts enabling Dapps to function cross-chain
Off-Chain Components
Off-chain components form the other half of Wormhole's architecture.
Off-chain components include:
Guardian Network: This consists of validators in a p2p network.
Guardian: These are validators contributing to the VAA multisig.
Spy: Validators helping to scale up VAA distribution.
Wormhole was built on the idea that a decentralized set of “Guardians” (aka nodes/validators) can be trusted to vigilantly observe, validate, and verify messages from the Wormhole Core Bridge contracts on each supported chain. The Guardian Network is made up of 19 validators or Guardians.
Wormhole also features an API that allows you to retrieve details for a VAA or the guardian network.
Finally, the Relayers - off-chain processes relay a VAA to the target chain. This includes Automatic Relayers, forming a decentralized network delivering messages requested on-chain, and Specialized Relayers, handling VAAs for specific protocols or cross-chain applications, and executing custom logic off-chain to save gas costs and increase cross-chain compatibility.
Wormhole’s VAAs
A simple analogy to understand guardians is that they’re like the border agents you’d have when you're trying to go to different countries who will stamp the visa saying this is legit and this is not.
They create Verifiable Action Approvals (VAAs), the signed attestations of an observed message.
They implement emitVAA() and verifyVAA() functions. The functions emitVAA() and verifyVAA() are implemented. Verifiable Action Approval, or VAA, is a struct that has guardian signatures and your message payload.
Every VAA is represented as a two-part byte array called the Body and the Header.
Information on the guardians and their signatures can be found in the header:
byte version (VAA Version)
u32 guardian_set_index (Indicates which guardian set is signing)
u8 len_signatures (Number of signatures stored)
[][66]byte signatures (Collection of ecdsa signatures)The message's full details, including the message payload, sequence, emitter_chain, emitter_address, and timestamp of the source transaction, are contained in the Body:
u32 timestamp (Timestamp of the block where the source transaction occurred)
u32 nonce (A grouping number)
u16 emitter_chain (Wormhole ChainId of emitter contract)
[32]byte emitter_address (Emitter contract address, in Wormhole format)
u64 sequence (Strictly increasing sequence, tied to emitter address & chain)
u8 consistency_level (What finality level was reached before emitting this message)
[]byte payload (VAA message content)VerifyVAA accepts VAA and compares it with the guardian's signatures to ensure the validity of the proof. emitVAA reads and publishes messages to the "mempool" of VAAs.
The VAA payload is as follows:
// head
byte version // VAA Version
u32 guardian_set_index // Indicates which guardian set is signing
u8 len_signatures // Number of signatures stored[][66]byte signatures // Collection of ecdsa signatures
// body
u32 timestamp
u32 nonce
u16 emitter_chain
[32]byte emitter_address
u64 sequence
u8 consistency_level
[]byte payloadEach Guardian observes and signs messages in isolation, with the resulting collection of signatures representing proof that a certain message is agreed upon by the Wormhole network. All of these signatures are then combined and saved in stored[][66]byte.
Specifically, sequence plays a crucial role in guaranteeing that every VAA for a message is distinct (that is, two distinct messages with identical message content would have different VAAs).
Every time the publishMessage function is called, the sequence number is increased by 1 in the useSequence function:
This ensures that the same message is never conveyed twice.
The message content is contained in the payload byte array. The transfer amount, token address, token chain, recipient address, target chain ID, transfer fee, etc. are included, for instance, in a token transfer:
struct Transfer {
// PayloadID uint8 = 1
uint8 payloadID;
// Amount being transferred (big-endian uint256)
uint256 amount;
// Address of the token. Left-zero-padded if shorter than 32 bytes
bytes32 tokenAddress;
// Chain ID of the token
uint16 tokenChain;
// Address of the recipient. Left-zero-padded if shorter than 32 bytes
bytes32 to;
// Chain ID of the recipient
uint16 toChain;
// Amount of tokens (big-endian uint256) that the user is willing to pay as relayer fee. Must be <= Amount.
uint256 fee;
}Remember, a message is only authentic if 2/3rds+ of the Guardians have signed it. This is comparable to users signing transactions on a Gnosis multi-sig wallet independently.
Wormhole Queries
Wormhole Queries is a feature that allows you to quickly and securely access data stored on a blockchain, even if you're currently working on a different blockchain.
Before Wormhole Queries, placing smart contracts onto another blockchain to "push" (publish) data periodically was necessary to obtain state data from that chain. A different way to access cross-chain data is using Wormhole Queries, which offers a "pull" mechanism for users to seek information and obtain attestations from Wormhole Guardians. With pull queries, gas expenses are reduced by approximately 84%, making this operation cheaper and faster than before.
Developers can submit queries to the Guardian Network and retrieve state data from compatible blockchains, hence eliminating the need for Guardians to broadcast data.
The Guardian network receives query requests, processes them by executing against RPC nodes to send them to the required chain, receives the results, validates the requests, and returns the requested data.
An attested response becomes the result.
Wormhole Portal Bridge
The xLabs team created Portal, a token bridge that implements a lock-and-mint procedure to move assets between chains using Wormhole's messaging protocol.
A lock-and-mint procedure essentially involves locking assets in a smart contract, as opposed to burning assets on the source chain. Next, on the destination chain, an IOU, a wrapped version of the token, is created.
The origin chain emits a message saying the tokens have been locked in the following structure:
u8 payload_id = 1 Transfer
u256 amount Amount of tokens being transferred.
u8[32] token_address Address on the origin chain.
u16 token_chain Numeric ID for the origin chain.
u8[32] to Address on the destination chain.
u16 to_chain Numeric ID for the destination chain.
u256 fee Portion of amount paid to a relayer.However, the implementation of how the tokens were locked is not specified in this event. The token bridge's implementation will determine whether they were held in custody or a smart contract.
Users can utilize the portal to connect any token between chains that Wormhole supports. Wormhole supports 42 blockchains as of February 18th (including testnets).
The USDC bridge, built by Circle, enables bridging USDC without gas fees between CCTP-supported chains. CCTP uses a burn-and-mint process and supports Arbitrum, Avalanche, Base, Ethereum, Noble, OP Mainnet, and Polygon PoS, with support for Solana expected to be added soon.
Apart from token bridges, Wormhole’s messaging layer can also be used for NFT bridging.
The most popular example of this is the migration of DeGods and y00ts, which initially relocated from Solana to Ethereum and Polygon, respectively. This migration was through Wormhole using a burn-and-mint process.
NFT holders on Solana burned their original NFT via a smart contract and redeemed their newly minted ERC-721 on Ethereum and Polygon directly within their wallets.
On fees, there are two types of fees:
transaction fees charged by the bridge for facilitating cross-chain services and
gas fees payable to both sender and receiver chains.
Gas fees are usually paid on the target chain since that is where the transaction is resolved. Users can utilize the bridge to pay a portion of the token being sent via relayers if they do not have the native currency on the target chain. The gas cost on the target chain is subsequently covered by the relayers. To make them easier to use, dapps developed on Wormhole frequently compensate users via meta-transactions.
Native chains like BSC and Solana typically charge modest gas fees. However, if a transfer involves a stablecoin, an additional stability fee may be charged.
Ethereum has significantly higher gas fees than other chains, often spiked into double digits, making cross-chain transfers involving Ethereum potentially more expensive.
Although the most popular use case for Wormhole currently is asset bridging, the protocol also enables other, more mature use cases, such as cross-chain governance and oracles.
For example, Uniswap leverages Wormhole for cross-chain governance. Uniswap Governance is on Ethereum Mainnet, meaning that decisions are made on Ethereum through token votes. However, Uniswap exists across many chains, including L2s and alt-EVMs.
Within these deployments, holders must be able to participate and inherit governance decisions made on Ethereum Mainnet. This can be done in a decentralized manner through Wormhole’s messaging layer, which enables Uniswap governance to send data from Ethereum Mainnet to target chains.
Another relevant use case for Wormhole is its utilization by Pyth. Pyth is a low-latency, pull-based oracle network that provides price feeds across multiple chains. Pyth uses Wormhole’s messaging layer to send price feeds and data cross-chain.
Pyth receives data from market makers, financial institutions, etc., who broadcast price feeds to Pythnet—a fork of the Solana SVM—with the sole purpose of aggregating price feeds from different publishers. Wormhole enables Pyth to deliver these price feeds cross-chain to dApps on all Wormhole-supported chains by collecting the aggregated data and bridging it across chains.
Mastering the Tools
Wormhole has two ways to interact with the protocol
Wormhole connect
Wormhole SDK
A frontend-embeddable widget called Wormhole Connect makes it simple for developers to incorporate bridges that use Wormhole Messaging. It allows for in-app bridging, transfers across various blockchains without leaving the application, and gasless and gas-dropoff (paying gas only on the source chain) transfers.
While offering the same capability as Wormhole Connect, the Wormhole SDK requires more work and implementation. Like Connect, the Wormhole SDK enables developers to create protocols on top of Wormhole Messaging and communicate with chains that Wormhole supports using TypeScript modules.
Wormhole has an SDK that serves as a gateway to building on the Wormhole network.
The SDK currently supports popular programming languages like Rust, JavaScript, and Go, allowing developers to choose their preferred environment. It provides APIs for seamless asset transfers, data message exchange, and interaction with the Guardian Network.
Wormhole’s SDK can be found in the core repository here and is available on npm.
It can be installed using npm:
npm i @certusone/wormhole-sdkThese RPC nodes are maintained by the Guardians to help fetch VAAs and query the Wormhole network. For the main guardian RPC:
const MAINNET_GUARDIAN_RPC: string[] = [
"https://api.wormholescan.io", // Explorer offers a guardian equivalent endpoint for fetching VAAs
"https://wormhole-v2-mainnet-api.mcf.rocks",
"https://wormhole-v2-mainnet-api.chainlayer.network",
"https://wormhole-v2-mainnet-api.staking.fund",
]For Testnet Guardian RPC:
const TESTNET_GUARDIAN_RPC: string[] = [
"https://api.testnet.wormholescan.io", // Explorer offers a guardian equivalent endpoint for fetching VAAs
]For Testnet Guardian Public Key”
const TESTNET_GUARDIAN_PUBKEY: string = "0x13947Bd48b18E53fdAeEe77F3473391aC727C638"Putting theory into practice
Let's use Wormhole to transmit a message from Solana to Ethereum.
On Solana, invoking a method on another contract requires us to provide certain accounts. This can be achieved through Cross Program Invocation (CPI).
To facilitate this process, the Wormhole TypeScript SDK has a convenient function called getWormholeCpiAccounts which we'll employ to obtain the required accounts.
const wormhole = getWormholeCpiAccounts(
CORE_BRIDGE_PID, // Core Wormhole Contract for Solana
KEYPAIR.publicKey,
program.programID, // Your Solana Program ID
// And below is a PDA for the Sequence Tracker account
deriveAddress([Buffer.from("sent"), 0], program.programID)
);The function mentioned above will return the following accounts we specify in Anchor.
#[account(
mut,
seeds = [wormhole::BridgeData::SEED_PREFIX],
bump,
seeds::program = wormhole_program,
)]
pub wormhole_bridge: Account<'info, wormhole::BridgeData>,
#[account(
mut,
seeds = [wormhole::FeeCollector::SEED_PREFIX],
bump,
seeds::program = wormhole_program
)]
pub wormhole_fee_collector: Account<'info, wormhole::FeeCollector>,
#[account(
init,
payer = owner,
seeds = [WormholeEmitter::SEED_PREFIX],
bump,
space = WormholeEmitter::MAXIMUM_SIZE
)]
pub wormhole_emitter: Account<'info, WormholeEmitter>,
#[account(
mut,
seeds = [
wormhole::SequenceTracker::SEED_PREFIX,
wormhole_emitter.key().as_ref()
],
bump,
seeds::program = wormhole_program
)]
pub wormhole_sequence: UncheckedAccount<'info>,
#[account(
mut,
seeds = [
SEED_PREFIX_SENT,
&wormhole::INITIAL_SEQUENCE.to_le_bytes()[..]
],
bump,
)]
pub wormhole_message: UncheckedAccount<'info>,
pub clock: Sysvar<'info, Clock>,
pub rent: Sysvar<'info, Rent>,Having completed these configurations, we can now proceed further.
The main way our Emitter interacts with the Wormhole is via the core contract. We will invoke the post_message method, which is essentially a way for us to send our message across the chain. The function implementation is as follows:
pub fn post_message<'info>(
ctx: CpiContext<'_, '_, '_, 'info, PostMessage<'info>>,
nonce: u32,
payload: Vec<u8>,
finality: Finality,
) -> Result<()> {Here's what each part means:
payload: This is our actual message - the "Hello from the other side" of blockchain. It's an arbitrary byte array that might have a maximum length due to some limitations of blockchains.
finality: This is our protective gear against reorgs and rollbacks, specifying the level of finality before the Wormhole VAA gets our message.
nonce: This is a unique index for the message that will be used to generate Batch VAAs.
sequenceNumber: A unique index for the message. When combined with the emitter contract address and emitter chain ID, we can retrieve the corresponding VAA from a guardian network node.
And with those explanations, we're ready to look at our Rust code snippet for posting a message:
let payload: Vec<u8> = "Hello from the other side".as_bytes().to_vec();
let nonce: u32 = 0;
let finality = wormhole::Finality::Confirmed as u8;
match wormhole::post_message(
CpiContext::new_with_signer(
ctx.accounts.wormhole_program.to_account_info(),
wormhole::PostMessage {
config: ctx.accounts.wormhole_bridge.to_account_info(),
message: ctx.accounts.wormhole_message.to_account_info(),
emitter: ctx.accounts.wormhole_emitter.to_account_info(),
sequence: ctx.accounts.wormhole_sequence.to_account_info(),
payer: ctx.accounts.owner.to_account_info(),
fee_collector: ctx.accounts.wormhole_fee_collector.to_account_info(),
clock: ctx.accounts.clock.to_account_info(),
rent: ctx.accounts.rent.to_account_info(),
system_program: ctx.accounts.system_program.to_account_info(),
},
&[
&[
SEED_PREFIX_SENT,
&wormhole::INITIAL_SEQUENCE.to_le_bytes()[..],
&[*ctx.bumps.get("wormhole_message")?,
],
&[wormhole::SEED_PREFIX_EMITTER, &[&ctx.accounts.wormhole_emitter.bump]],
],
),
nonce,
payload,
finality.into(),
) {
Ok(_) => {}
Err(e) => {
msg!("Error Posting Message: {:?}", e);
return Err(e);
}
}In the Rust code above, the payload is set to the message we want to send ("Hello from the other side"). The method post_message is then called with several parameters. In case of an error during the execution of this method, it gets captured and logged for troubleshooting.
Once we successfully execute the CPI, we get a sequence number. This special number allows us to retrieve our Verifiable Action Approval (VAA). If you have the local wormhole validator running (‣), You're one step away from fetching your VAA! All you have to do is visit the following URL, replacing [wormholeChainId], [emitterAddr], and [seq] with your specific details:
<http://localhost:7071/v1/signed_vaa/${wormholeChainId}/${emitterAddr}/${seq}>Here is our VAA, looking like a cryptic piece of alien tech:
010000000001009ba8eca3ad035da554498a113bc460b05f18849c1fb256540c05cedc9e9918846326ac799d548392319ea93e0721da8fc231f71e64097b398cff133d4d9843e7000000000100000001000104a97fa4da1675cf1a83750edcc176e956fe37fc0ffd8db87eeff6cc78ebd51b000000000000000001656c6c6f2066726f6d20746865206f746865722073696465You can use wormhole's vaa-parser to decipher it and get a good look at the payload.
Our final mission is to transport the above VAA to Ethereum and decode the payload to access its contents.
Here is the interface for applications to interact with Wormhole's Core Contract to publish VAAs or verify and parse received VAAs. Instantiating the interface will depend on the contract address of your development ecosystem and blockchain.
Below is an example line of code to instantiate the interface for mainnet Ethereum:
address private wormhole_core_bridge_address = address(0x98f3c9e6E3fAce36bAAd05FE09d375Ef1464288B);
IWormhole core_bridge = IWormhole(wormhole_core_bridge_address);Now, we can parse the VAAs emitted by other chains.
function receiveEncodedMsg(bytes memory encodedMsg) public {
(IWormhole.VM memory vm, bool valid, string memory reason) = core_bridge.parseAndVerifyVM(encodedMsg);
//Check Wormhole Guardian Signatures
// If the VM is NOT valid, will return the reason it's not valid
// If the VM IS valid, reason will be blank
require(valid, reason);
//Check that the message hasn't already been processed
require(!_completedMessages[vm.hash], "Message already processed");
_completedMessages[vm.hash] = true;
//Do the thing
current_msg = string(vm.payload);
emit message(current_msg);
}Say you’ve deployed your contract on Eth mainnet but you want to send a message to Solana. So, using the Wormhole SDK, you can wrap your address in IWormhole and use _wormhole.publishMessage() with:
import "./interfaces/IWormhole.sol";
contract Messenger {
// Hardcode the Wormhole Core Bridge contract address
// In a real contract, we would set this in a constructor
address a = address(0xC89Ce4735882C9F0f0FE26686c53074E09B0D550);
IWormhole _wormhole = IWormhole(a);
function sendStr(bytes memory str, uint32 nonce) public returns (uint64 sequence) {
sequence = _wormhole.publishMessage(nonce, str, 1);
return sequence;
}
function wormhole() public view returns (IWormhole) {
return _wormhole;
}
}Transferring Ethereum tokens to Solana:
// Submit transaction
const receipt = await transferFromEth(
ETH_TOKEN_BRIDGE_ADDRESS, // specified in the doc
signer,
tokenAddress, // WETH token address
amount,
CHAIN_ID_SOLANA,
recipientAddress // already attested address on solana
);
// signedVAA needs to be fetched
const { signedVAA } = await getSignedVAA(
WORMHOLE_RPC_HOST,
CHAIN_ID_ETH,
emitterAddress,
sequence
);
// post signVAA
await postVaaSolana(
connection,
wallet,
SOL_BRIDGE_ADDRESS,
payerAddress,
signedVAA
);
// redeem WETH on Solana
const transaction = await redeemOnSolana(
connection,
SOL_BRIDGE_ADDRESS,
SOL_TOKEN_BRIDGE_ADDRESS,
payerAddress,
signedVAA,
isSolanaNative,
mintAddress
);And there you have it! You've just successfully sent a message across chains.
Now, we talked about bridges and cross-chain building, but why do any of these matter?
The real reason — xDapps.
xDapps
xDapps are any applications built using the prowess of Wormhole.
They are the type of chain-agnostic application that can take advantage of xAssets (cross-chain assets) and xData (cross-chain data).
“Wormhole is a way for users to not care about developer choices.”
Imagine that your bank's infrastructure is based on Google Cloud, and you wish to purchase something on Amazon whose infrastructure is built on AWS. You couldn't purchase from Amazon because your bank used a separate development infrastructure, which is absurd.
As things are right now, it is not easy to buy things on Solana with the money you have in Ethereum.
xDapps, being cross-chain, provides an answer to this issue.
In a nutshell, it makes the web3 UX feel like web2.
For instance, a Solana-based application might support direct Ethereum deposits! The Portal Token Bridge will pick up the deposit and send it to the target chain, in this case Solana, if the developer just integrates the Wormhole SDK into their front end. You can now purchase this Amazon item directly from your bank without worrying about the technology behind it.
But, Why xDapps?
More chains, more users!
This ultimately means that your product can be used by any user on any chain. Developers simply want to uphold user rights and introduce cryptocurrency to the next billion people. Thus, expanding into new chains will address more users, which will increase to users.
This is what several projects have shown us.
Over 140 million people play the move-to-earn game Sweat Economy on web2, and web3 platforms.
Their token SWEAT originally existed on the NEAR blockchain as a NEP-141 token. Since NEAR certainly doesn't have all the users, they used Wormhole to bridge over to Ethereum. It is now also accessible as a native ERC-20 token. That means people on Ethereum can directly use it and all the liquidity from Ethereum can be applied to Sweat Economy.
Product Ideation
The chains of the past must be broken before we are free to shape the future - Franklin D. Roosevelt
These wise words ring true for the blockchain industry today. Isolated ecosystems are hindering innovation and limiting user experience.
To that effect, let’s take a look at some unique and viable product ideas leveraging the Wormhole framework:
Build a single sign-on system using Wormhole's interoperability to manage a user's reputation and digital footprint across different blockchains. This allows users to seamlessly interact with dApps on any chain while maintaining a unified identity.
Develop a DEX that leverages Wormhole bridges to aggregate liquidity from various DeFi protocols across different blockchains. Users can swap tokens seamlessly between chains like Ethereum, Solana, and Avalanche with deep liquidity pools, all within a single interface.
Create a unified lending and borrowing platform that utilizes Wormhole's interoperability. This platform can connect users to the most attractive interest rates and loan options across various DeFi protocols, regardless of the underlying blockchain they reside on.
Develop a game that utilizes Wormhole bridges to enable the seamless transfer and use of in-game assets (characters, items) across different blockchain-based virtual worlds. This fosters a truly interconnected gaming experience where players can leverage their assets across various metaverses.
Build an NFT marketplace powered by Wormhole that allows users to buy, sell, and trade NFTs irrespective of their native blockchain. This eliminates the need for multiple wallets and fragmented ecosystems, fostering a more unified NFT trading experience.
Currently, there is a bit of difficulty in obtaining a holistic view of DeFi activity, NFT trends, and overall market insights due to siloed data across different blockchains. So, someone can develop a data analytics platform that utilizes Wormhole bridges to aggregate and analyze data from various blockchains.
WORMHOLE AND COSMOS
It is noteworthy that Osmosis will be among the first app-chains to be integrated with Wormhole Gateway.
Acknowledged as the front-runner in the Cosmos ecosystem with respect to IBC activity, volume, and fees collected, it commands respect in the larger DeFi scene. The Co-Founder of Osmosis Labs; Sunny Aggarwal, showcased this partnership during Osmocon, a community conference that took place in Paris.
Gateway on Cosmos came into being due to several circumstances.
But primarily, the Cosmos SDK was essential because it improved Wormhole's openness and independence. Wormhole was also able to use IBC light clients, which are regarded as the industry standard for security, thanks to the SDK. This also increases Wormhole's ability to provide a continuous asset and data flow between blockchains.
Conclusion:
The future of blockchain is undoubtedly multichain.
Wormhole provides the tools and infrastructure to be a pioneer in this revolution. With its robust SDK and thriving community, Wormhole empowers developers to build the next generation of dApps.
So, delve into the Wormhole, explore its potential, and be a part of shaping the future of a truly interconnected blockchain ecosystem.
Remember, this is just a starting point. As the blockchain space evolves, so will the possibilities with Wormhole. Stay curious, keep exploring, and be a part of the exciting future of multichain development!
Community & Resources
References
Great piece brother!
You can use https://wormholescan.io/#/developers/vaa-parser instead of https://vaa.dev