SDK Docs

The Wormhole Typescript SDK is useful for interacting with the chains Wormhole supports and the protocols built on top of Wormhole.

Warning

⚠️ This package is a Work in Progress so the interface may change and there are likely bugs. Please report any issues you find. ⚠️

Installation

Basic

Install the (meta) package

npm install @wormhole-foundation/sdk

This package combines all the individual packages in a way that makes setup easier while still allowing for tree shaking.

Advanced

Alternatively, for an advanced user, install a specific set of the packages published.

# constants
npm install @wormhole-foundation/sdk-base
# contract interfaces, basic types, vaa payload definitions
npm install @wormhole-foundation/sdk-definitions
# Evm specific utilities
npm install @wormhole-foundation/sdk-evm
# Evm TokenBridge protocol client
npm install @wormhole-foundation/sdk-evm-tokenbridge

Usage

Getting started is simple, just import Wormhole and the Platform modules you wish to support

See example here

And pass those to the Wormhole constructor to make them available for use

See example here

With a configured Wormhole object, we have the ability to do things like; parse addresses for the platforms we passed, get a ChainContext object, or fetch VAAs.

See example here

See example here

Optionally, the default configuration may be overriden in the case that you want to support, eg a different RPC endpoint.

See example here

Concepts

Understanding several higher level concepts of the SDK will help in using it effectively.

Platforms

Every chain is its own special snowflake but many of them share similar functionality. The Platform modules provide a consistent interface for interacting with the chains that share a platform.

Each platform can be installed separately so that dependencies can stay as slim as possible.

Chain Context

The Wormhole class provides a getChain method that returns a ChainContext object for a given chain. This object provides access to the chain specific methods and utilities. Much of the functionality in the ChainContext is provided by the Platform methods but the specific chain may have overridden methods.

The ChainContext object is also responsible for holding a cached rpc client and protocol clients.

Addresses

Within the Wormhole context, addresses are often normalized to 32 bytes and referred to in this SDK as a UniversalAddresses.

Each platform comes with an address type that understands the native address formats, unsurprisingly referred to as NativeAddress. This abstraction allows the SDK to work with addresses in a consistent way regardless of the underlying chain.

Tokens

Similar to the ChainAddress type, the TokenId type provides the Chain and Address of a given Token.

Signers

In order to sign transactions, an object that fulfils the Signer interface is required. This is a simple interface that can be implemented by wrapping a web wallet or other signing mechanism.

See the testing signers (Evm, Solana, ...) for an example of how to implement a signer for a specific chain or platform.

Protocols

While Wormhole itself is a Generic Message Passing protocol, a number of protocols have been built on top of it to provide specific functionality.

Each Protocol, if available, will have a Platform specific implementation. These implementations provide methods to generate transactions or read state from the contract on-chain.

Wormhole Core

The protocol that underlies all Wormhole activity is the Core protocol. This protocol is responsible for emitting the message containing the information necessary to perform bridging including Emitter address, the Sequence number for the message and the Payload of the message itself.

See example here

Within the payload is the information necessary to perform whatever action is required based on the Protocol that uses it.

Token Bridge

The most familiar protocol built on Wormhole is the Token Bridge.

Every chain has a TokenBridge protocol client that provides a consistent interface for interacting with the Token Bridge. This includes methods to generate the transactions required to transfer tokens, as well as methods to generate and redeem attestations.

Using the WormholeTransfer abstractions is the recommended way to interact with these protocols but it is possible to use them directly

Supported protocols are defined in the definitions module.

Transfers

While using the ChainContext and Protocol clients directly is possible, to do things like transfer tokens, the SDK provides some helpful abstractions.

The WormholeTransfer interface provides a convenient abstraction to encapsulate the steps involved in a cross-chain transfer.

Token Transfers

Performing a Token Transfer is trivial for any source and destination chains.

We can create a new Wormhole object and use it to to create TokenTransfer, CircleTransfer, GatewayTransfer, etc. objects to transfer tokens between chains. The transfer object is responsible for tracking the transfer through the process and providing updates on its status.

See example here

Internally, this uses the TokenBridge protocol client to transfer tokens. The TokenBridge protocol, like other Protocols, provides a consistent set of methods across all chains to generate a set of transactions for that specific chain.

Native USDC Transfers

We can also transfer native USDC using Circle's CCTP

See example here

Gateway Transfers

Gateway transfers are transfers that are passed through the Wormhole Gateway to or from Cosmos chains.

A transfer into Cosmos from outside cosmos will be automatically delivered to the destination via IBC from the Gateway chain (fka Wormchain)

See example here

A transfer within Cosmos will use IBC to transfer from the origin to the Gateway chain, then out from the Gateway to the destination chain

See example here

A transfer leaving Cosmos will produce a VAA from the Gateway that must be manually redeemed on the destination chain

See example here

Recovering Transfers

It may be necessary to recover a transfer that was abandoned before being completed. This can be done by instantiating the Transfer class with the from static method and passing one of several types of identifiers.

A TransactionId or WormholeMessageId may be used to recover the transfer

See example here

Routes

While a specific WormholeTransfer may be used (TokenTransfer, CCTPTransfer, ...), it requires the developer know exactly which transfer type to use for a given request.

To provide a more flexible and generic interface, the Wormhole class provides a method to produce a RouteResolver that can be configured with a set of possible routes to be supported.

See example here

Once created, the resolver can be used to provide a list of input and possible output tokens.

See example here

Once the tokens are selected, a RouteTransferRequest may be created to provide a list of routes that can fulfil the request

See example here

Choosing the best route is currently left to the developer but strategies might include sorting by output amount or expected time to complete the transfer (no estimate currently provided).

After choosing the best route, extra parameters like amount, nativeGasDropoff, and slippage can be passed, depending on the specific route selected and a quote can be retrieved with the validated request.

See example here

Finally, assuming the quote looks good, the route can initiate the request with the quote and the signer

See example here

Note: See the router.ts example in the examples directory for a full working example

See also

The tsdoc is available here

Last updated

Was this helpful?