Skip to content

set wormhole address in solana binary by patching it, to enable other SVM chains to work with the CLI #658

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

evgeniko
Copy link
Collaborator

@evgeniko evgeniko commented Jul 21, 2025

From @kcsongor in commit e43c778

"cli: set wormhole address in solana binary by patching it
The problem: solana binaries contain program addresses embedded into
them. Specifically, NTT includes the address of the Wormhole program
it's linked against. Which Wormhole address to include is controlled via
feature flags in the wormhole-anchor-sdk crate, which supports one of
mainnet, devnet, and localhost. For other SVM chains, like Fogo, we
can't build this binary correctly, because there is no way to tell it
which core address to use.

One solution is to roll out an updated version of the
wormhole-anchor-sdk, which allows setting the Wormhole address via an
environment variable. That is likely the prudent solution, but it will
need to be backported to older NTT versions (in case a Fogo deployer
wants to deploy, say, 3.0.0, instead of the main HEAD).

Another solution, which we adopt in this commit, is simply patching the
binary. In other words: compile the binary with the solana flag, then
replace the solana address with the desired address. This seems to work
just fine, there is no checksum signing on the binaries or anything. It
also makes compilation a bit faster, because we don't need to recompile
anything between different targets.

Not sure if we should keep this, but will do for now."

kcsongor and others added 2 commits July 21, 2025 18:20
The problem: solana binaries contain program addresses embedded into
them. Specifically, NTT includes the address of the Wormhole program
it's linked against. Which Wormhole address to include is controlled via
feature flags in the wormhole-anchor-sdk crate, which supports one of
mainnet, devnet, and localhost. For other SVM chains, like Fogo, we
can't build this binary correctly, because there is no way to tell it
which core address to use.

One solution is to roll out an updated version of the
wormhole-anchor-sdk, which allows setting the Wormhole address via an
environment variable. That is likely the prudent solution, but it will
need to be backported to older NTT versions (in case a Fogo deployer
wants to deploy, say, 3.0.0, instead of the main HEAD).

Another solution, which we adopt in this commit, is simply patching the
binary. In other words: compile the binary with the solana flag, then
replace the solana address with the desired address. This seems to work
just fine, there is no checksum signing on the binaries or anything. It
also makes compilation a bit faster, because we don't need to recompile
anything between different targets.

Not sure if we should keep this, but will do for now.
@evgeniko evgeniko requested review from kcsongor and nvsriram July 21, 2025 16:44
Copy link
Collaborator

@nvsriram nvsriram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why we check this again when it is already done at the start of this function here? Or am I missing something?
Edit: Nvm, I misread what the check was doing.

Copy link
Collaborator

@nvsriram nvsriram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants