Adapters

Override core logic for signing messages and sending transactions

The Reservoir SDK normalizes wallets allowing developers to override the underlying handlers for signing messages and sending transactions. This functionality opens the door to many use cases, some examples are:

  • Using a different underlying library to sign messages and submit transactions (ethersjs, web3, viem, etc)
  • Adding additional logs/analytics during these steps
  • Integrating with third party services such as gelato or open zeppelin defender

All Reservoir SDK actions require passing in either a ReservoirWallet object or a viem WalletClient object. The ReservoirWallet interface normalizes the following methods:

Method NameDescriptionArguments
handleSignMessageStepThis handler is triggered whenever the SDK encounters a signature step and requires a signature.item: This is a SignatureStepItem, referring to the item returned from the execute api call. It has all the necessary data to sign a message depending on the signatureKind. Refer to the type for more information.
step: This is a step returned from the execute api call. The key piece here is the id, description and action which will give you more context around the step and what it's purpose is. Refer to the type for more information.
handleSendTransactionStepThis handler is triggered whenever the SDK encounters a transaction step and needs to send a transaction.chainId: This is the chainId that the step is targeting.
item: This is a TransactionStepItem, referring to the item returned from the execute api call. It has all the necessary data to send the transaction (data, from, to, etc). Refer to the type for more information.
step: This is a step returned from the execute api call. The key piece here is the id, description and action which will give you more context around the step and what it's purpose is. Refer to the type for more information.
addressThis method is an abstraction for retrieving the address performing the signing/sending of the transaction. It's mainly used to fill in the taker/maker in the SDK actions.N/A
transportThis object is automatically extracted from the wallet so long as you're using viem (the default) wallet adapter. Otherwise you can create and pass in a viem transport which will be used internally to check the transaction status. N/A This is a property, not a function

Refer to the ReservoirWallet type definition for more information.

Writing a custom adapter

Below is a stubbed out example illustrating the anatomy of the adapter, in your implementation you would add your custom logic:

import { ReservoirWallet } from '@reservoir0x/reservoir-sdk'

//Add any additional parameters required to create the adapter
export const yourCustomAdapter = (): ReservoirWallet => {
  return {
    address: async () => {
      //Your custom code, must return an address string
    },
    handleSignMessageStep: async (stepItem, step) => {
      //Your custom code to sign a message, must return a signature
    },
    handleSendTransactionStep: async (chainId, stepItem, step) => {
      //Your custom code to send a transaction, must return a transaction hash
    },
    transport: http()
  }
}

Official Adapters

  • Viem wallet adapter: This is used internally to convert the viem WalletClient into a ReservoirWallet, making the SDK easier to use for the standard library (viem). There's no need to use this externally but we do expose it. It's also great reference material for making your own adapter.
  • Ethers wallet adapter: This adapter was created to allow applications using the Reservoir SDK to continue receiving updates while planning their migration to viem. While we urge teams to upgrade to viem we understand that adequate planning is required to make such a vital migration, we hope that this adapter can help bridge the gap until then.
  • Gelato adapter: This adapter was created to support applications wanting to provide gasless transactions via gelato to their users. This package was developed by Privy in partnership with the Reservoir team. For now only sponsored transactions are supported.
  • Defender Relay adapter:This adapter was created to support users wanting to use Open Zeppelins relayer to handle reservoir-sdk server side transactions. Using this adapter allows for transactions to be executed without directly exposing your private key, and relies on Open Zeppelins custom HTTP transaction service.