02 Emerging technology / Web3 2022
Messina Bridge
Reducing the work and uncertainty of cross-chain transfers.
Undercurrent Capital’s bridge between Ethereum and Algorand. A transfer that went through on Ethereum could still stall on Algorand: newcomers couldn’t see its progress, had no ALGO to pay the fee and had to claim their tokens by hand. We launched the bridge, then added gas support, stage-by-stage status and automatic delivery.
Discovery
Three recurring problems in newcomer feedback.
At Undercurrent Capital, we were building a way to move assets between Ethereum and Algorand. A successful source transaction was only the beginning: people still needed to understand the wait, prepare the receiving wallet and finish delivery on another chain.
Release phases I led. This case covers the initial bridge and the releases that followed:
- October 2022: token transfers. The team announced the mainnet launch between Ethereum and Algorand.
- After launch: help with gas and delivery. Messina announced the ALGO airdrop on 20 October 2022. An October team update also described the relay service.
- Later releases: recovery and expansion. I continued leading the product with design and engineering as we expanded its capabilities, including non-fungible token (NFT) bridging. The guide examples below show later versions of the product.
I heard these problems repeatedly in informal feedback on Reddit, Discord and Twitter during testnet development and after mainnet launch.
- Without a clear status, people couldn’t tell which part of the transfer was still pending.
- Claiming on Algorand required ALGO for gas, which newcomers didn’t have yet.
- Tokens had to be claimed manually with an Algorand wallet.
Design
Make the transfer easier to finish.
Working with the designer. I helped the product designer build Web3 context through analogies and competitor walkthroughs. We framed protocol constraints as usability problems: what someone needed to know, approve or recover at each step.
The designer owned the flows, information hierarchy and screen design, and engineering owned the contracts and their implementation. I led product scope and release priorities with engineering and coordinated launch marketing. The decisions below explain the reasoning behind the approach.
Decision 1
ALGO for the receiving wallet.
We added ALGO support so newcomers could finish the destination-side steps. The later flow checked the receiving wallet’s balance and airdropped ALGO when it was too low.
An exchange link would have sent someone away to acquire the token needed to finish this transfer. A warning explained the problem without resolving it; an on-chain swap could still require ALGO to transact. An airdrop addressed that initial funding gap directly, at the cost of funding and operating the service. It still left the recipient responsible for approving an asset opt-in.
Decision 2
A wait you can see.
We separated source confirmation, bridge verification and destination delivery so people could see what had finished and what was still pending.
A single time estimate would have hidden those dependencies and could become misleading when a chain or verification stage took longer. Email or Telegram alerts could bring someone back later, but would not explain the transfer while they were looking at it. Stage status answered that immediate question without requiring contact details. It could not promise a completion time or resolve a stalled transfer by itself.
- Source confirmation, bridge verification and delivery were shown as separate stages.
- Copy and explorer links let people inspect the source transaction.
- A pending stage showed where progress had stopped; it did not diagnose the cause.
Decision 3
Tokens delivered, not claimed.
For supported tokens, bridgers could enter a destination address and let Messina’s relay submit the destination claim. Manual claiming remained available. The relay followed the initial token bridge launch.
We considered using Wormhole’s relayers. I recall that the coordination would have delayed our launch, so we shipped the token bridge first and added our own relay. That gave us responsibility for operating delivery as well as the interface.
- Auto-delivery served people who had a destination address.
- Manual claiming stayed available as an alternative.
Decision 4
The whole cost up front.
We displayed the bridge fee and estimated network fees before review so someone could weigh the cost before committing funds. The quote was an estimate: network conditions and the transaction ultimately submitted could change the gas cost.
- The form distinguished the bridge fee from estimated network fees.
- The received amount made the bridge fee’s effect visible before review.
Decision 5
Recover without a second transfer.
We made recovery part of the product. Resume Bridging continued a transfer interrupted after the source transaction, so people could finish without starting again or relying only on support.
The source transaction hash identified the existing transfer. This put some retrieval work on the bridger, but preserved the transfer already committed on-chain. A different wallet could submit the claim while the assets still went to the original recipient. The recovery guide documents that constraint.
- The existing transfer was retrieved from its source chain and transaction hash.
- The unfinished stage continued, with the original recipient preserved.
- Another wallet could submit the destination claim without redirecting the assets.
Later product evolution: NFT bridging.
NFTs were a separate expansion beyond the initial newcomer transfer problems. The aim was to let creators and collectors use supported collections across chains. That added collection integration and ownership requirements to the product; it was not part of the October 2022 token-transfer scope.
Decision 6
Support collections across chains.
We extended the bridge to curated NFT collections, including existing collections and those using Messina’s standard. Curation limited which collections could be moved and made the integration scope explicit. Supporting a collection was a product and technical commitment, rather than a promise that every NFT could bridge.
The public NFT product describes cross-chain access and continuity of ownership as its goals.
- Existing collections could use lock-and-mint: custody on one chain, a representation on another.
- Messina-standard collections could use burn-and-mint to maintain one active instance across supported chains.
- This example shows the collection and ownership details before a transfer.
Build
How the bridge works.
Three technical constraints shaped the interface and release scope:
- Gas estimates were provisional. Ethereum exposes
eth_estimateGas; an estimate is not a guaranteed final fee. The interface needed to communicate that uncertainty. - Algorand assets required an opt-in. A receiving account had to authorise an asset opt-in and hold enough ALGO for the minimum balance and transaction fees. We surfaced the opt-in in the bridge, leaving the wallet approval with the bridger. Gas support did not remove that consent requirement.
- Contract changes needed coordinated releases. We kept integrations modular so new assets and chains could be added through planned engineering work. Deployed bytecode does not imply that a whole system is unchangeable: Ethereum supports upgrade patterns, and Messina’s public contract source includes an upgrade function.
In the primary Wormhole route, the source chain committed the transfer. Guardians signed a message called a Verified Action Approval (VAA). The destination verified it before delivering the assets. The diagrams below show this route as described in the public documentation.
System architecture
Contracts, Guardians and delivery.
The Next.js web app connects wallets to the source and destination chains. On the source chain, Messina’s bridge contract commits the transfer and Wormhole’s Core contract publishes a message. The off-chain Guardian network observes source finality and signs a VAA after quorum. Messina’s relay or a manual claim submits the VAA to the destination Core contract for verification; the destination bridge executes delivery to the original recipient.
Connect wallets · submit signed transactions · retrieve status
Source chain
Commit assets and the recipient.
Emit the source event.
Attestation + delivery
Attest to source finality.
Or submit a manual claim.
Destination chain
Verify the signed attestation.
Execute delivery to the recipient.
On-chain boundary Off-chain service boundary
Diagram preview
Verification and delivery were separate. Wormhole’s Guardians attested to the source message. Messina’s relay transported the signed VAA, or a person submitted it through a manual claim. Destination contracts verified it before execution. The relay made delivery easier; it didn’t replace verification. Messina’s messaging documentation also describes a separate Wormhole-derived layer for other supported routes.
The wait depended on the chain. Source confirmation and finality requirements came before the attestation. A source-chain tick showed progress, not proof that the destination had finished.
Delivery still had prerequisites. Destination execution needed gas. Receiving a token on Algorand also needed an asset opt-in. The relay and ALGO airdrop reduced the work for supported transfers; they didn’t remove those chain requirements.
Recovery architecture
Recover from the source of truth.
The transfer moves through source committed, attestation pending, destination claim and delivered. After a session or delivery interruption, the source chain and transaction hash retrieve the existing transfer. Recovery returns to pending attestation or an unfinished destination claim and preserves the original recipient.
- Source committed
Keep the transaction hash.
- Attestation pending
Wait for finality and quorum.
- Destination claim
Submit the signed VAA.
- Delivered
Original recipient receives assets.
Retrieve the original transfer and recipient.
Attestation, if pending.
Destination claim, if ready.
Diagram preview
Recovery picked up the existing transfer. Once the source chain had committed, a closed session or interrupted delivery didn’t undo the transaction. The bridger resumed with its chain and hash, then waited for attestation or finished the destination claim. The recipient stayed the same.
The stack behind it.
| Layer | Technology |
|---|---|
| EVM | Solidity |
| Algorand | PyTEAL / TEAL |
| Messaging | Wormhole + signed VAAs |
The bridge stack combined these technologies.
Launch
Launch and results.
I led product marketing in the run-up to launch with another product marketer, including partner coordination and the ALGO airdrop announcement. My product leadership continued through the later releases shown here.
The October 2022 launch announcement marks the Ethereum–Algorand bridge launch. Later guides and the public product show gas support, relay delivery, recovery and NFT bridging.
Three months after launch, Messina was No. 8 by value locked among Algorand protocols on DefiLlama, with US$3.76 million (Messina’s post, 13 January 2023). Value locked reflects assets held in the bridge, not the number of people or completed transfers.
We didn’t track completed transfers, so I can’t say how much these changes helped people finish.
One user described a smooth transfer of ETH and USDC:
“I was able to bridge ETH and USDC seamlessly!”
— hercules (@Hercules_algo), X post dated 4 March 2023
It’s one person’s account, not a measure of typical results.
If I were taking the bridge forward, I would:
- Measure completed transfers from day one, from source commitment to destination delivery, and use the drop-offs at each stage to guide the next iteration.
