# 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
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

```bash
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](/home/intlc/projects/proxmox/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:

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

For testnet:

```bash
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/](/home/intlc/projects/proxmox/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