proxmox/docs/03-deployment/WORMHOLE_NTT_EXECUTOR_OPERATOR_RUNBOOK.md

Wormhole NTT + Executor — operator runbook

Last updated: 2026-04-01
Purpose: Prepare a Wormhole operator environment for Native Token Transfers (NTT) using the modern Executor relay path, while clearly separating repo-local preparation from the protocol support boundary for Chain 138.

What this runbook completes

• installs the official ntt CLI
• bootstraps a local NTT project directory
• seeds environment templates and deployment placeholders
• records the current protocol boundary for Chain 138

What this runbook does not complete automatically

• deploying Wormhole contracts to a chain that is not currently listed as Wormhole-supported
• registering Chain 138 as a Wormhole chain
• providing Guardian / protocol-level support for Chain 138
• filling secrets, RPC URLs, or signing keys

Why Executor, not Standard Relayer

Wormhole’s own relayer docs now direct developers to the Executor framework and warn that the Standard Relayer is deprecated. New NTT integrations should be prepared with Executor in mind, not the legacy Standard Relayer path.

Chain 138 boundary

Before attempting a real Wormhole deploy, confirm the chain is officially supported:

• Wormhole chain IDs reference: https://wormhole.com/docs/products/reference/chain-ids/
• supported networks reference: https://wormhole.com/docs/products/reference/supported-networks/

As of this repo update, Chain 138 is not listed there, so a full Wormhole NTT or messaging deployment for Chain 138 is still blocked on Wormhole-side chain support or a separate custom-chain onboarding process.

That means:

• supported chains: you can prepare and deploy NTT + Executor normally
• Chain 138: you can prepare operator tooling and configs, but you should not mark a live Wormhole deployment complete

Repo-local preparation

1. Install the NTT CLI

bash scripts/wormhole/install-ntt-cli.sh

This follows Wormhole’s current guidance:

• install ntt
• ensure Bun v1.2.23 is available in PATH

2. Bootstrap a project

WORMHOLE_NTT_PROJECT_DIR=~/wormhole-ntt-mainnet \
WORMHOLE_ENVIRONMENT=Mainnet \
bash scripts/wormhole/bootstrap-ntt-project.sh

This creates an NTT project, initializes deployment.json, and copies repo example files for local editing.

3. Fill local env

Use config/wormhole/ntt-operator.example.env as the base for your local-only environment.

At minimum, fill:

• source RPC URL
• destination RPC URL
• deployer private key
• any Wormhole provider/API credentials you use internally

4. Check Executor support

Before a real transfer route, confirm the destination chain supports NTT with Executor:

curl -fsSL https://executor.labsapis.com/v0/capabilities | jq .

For testnet:

curl -fsSL https://executor-testnet.labsapis.com/v0/capabilities | jq .

Do not proceed with automated relaying unless the source/destination pair is supported there.

Suggested operator placement

Use the OP Stack deployer CT as the Wormhole preparation box:

• 5751 op-stack-deployer-1 at 192.168.11.69

That CT already has:

• baseline build tools
• SSH access for opuser
• repo bootstrap content

Artifact handling

Store non-secret outputs in:

• config/wormhole/deployed/

Examples:

• deployment.mainnet.json
• executor-capabilities.snapshot.json
• supported-chains.audit.md

Next real blockers

1. pick a Wormhole-supported source/destination pair if you want a live proof-of-path now
2. decide whether Chain 138 is waiting for official support or for a custom-chain onboarding effort
3. fill the local-only RPC + key material
4. run the actual ntt deployment flow from the bootstrapped project