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/sdkThis 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-tokenbridgeUsage
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?

