Skip to main content


HIP-338 compliant

We might be the first non-official library to support Hedera's standardized wallet proposal and we're damn proud of it.

Want to give it a spin? Make sure you have HashPack installed and then connect to the docs page by clicking

Wallet Button

Then get a hold of a Session that targets a Browser wallet and use it normally:

Live Editor

We need here to intentionally specify the { wallet: { type: 'Browser' } } object argument to ApiSession.default otherwise, fallowing normal parameters resolution, the strato bundle would have defaulted to using the implicit Sdk wallet type which was configured when bundling for use with these docs. This is actually the case for other live-code edits present on other pages.


Due to Hedera's pricing model as well as Query mechanics and, in general, overall Executable support from wallet extensions, only Transactions are currently supported by our wallet-bridge implementation.

This means that only wallet.getAccountBalance() is supported and that, consequently, wallet.getAccountInfo() and wallet.getAccountRecords() are not.

This also means that contract creation/querying is not currently supported. We plan on mitigating this with a future Strato release.

Under the hood

Hedera's SDK implementation

A LocalWallet and a LocalProvider have been developed by Hedera to wrap the traditional Client account-operated instance. As of hedera-sdk-js's v2.11.0, the only way to instantiate such a wallet is through the following environmental variables:

HEDERA_NETWORKThe name of the official1 network used by this wallet instance. Can be one of: testnet, previewnet or mainnet
OPERATOR_IDThe AccountId of the operator paying for the wallet's transactions
OPERATOR_KEYThe operator's private key

Following is a architecture diagram portraying the initial wallet-signer-provider implementation:

A couple of summarizing points here:

  • Wallet is an interface extending a Signer and having a Provider associated. It's basically the glue that ties everything up
  • As such Wallets are the objects that are meant to be hooked into in order to operate a Hedera session
  • The associated wallet account id information is something bound to the Wallet and made available through the Signer interface
  • Providers should only bridge the implementation with the data-source (which is most likely network based)
  • Providers should not have hard-coded account-ids on their instance and should, with respect to this data, be stateless

For a more detailed analysis, please have a look at the original HIP.

Strato's take


This feature is currently in active development. As such, it is very likely that the final API, once the stable release hits the streets, will differ.

Based on the original HIP-338 proposal, we went on and simplified the overall Wallet interface to a StratoWallet which only currently knows 2 operations:

  • executing Transactions and Querys
  • getting a TransactionReceipt for a TransactionResponse

Sign-ing mechanics are still being designed and considered and will probably see the light of day in a future release.

We then extracted away the Signer query calls and isolated them into their own SignerInfo interface. WalletInfo glues everything up nicely and is made available on every session at ApiSession.wallet.


As seen above, there are currently 2 types of wallet backends:

  • a, default, Sdk one which uses a re-implemented version of Hedera's LocalWallet and LocalProvider to also work with customnet networks
  • a Browser one which, when selected, looks at a global window.hedera object and uses that as the Wallet sync for all transactions of that particular session

For Browser wallets, property names can be changed via the HEDERAS_WALLET_WINDOW_PROPERTY_NAME/wallet.window.propName config.

The code for the HashPack HIP-338 wallet-bridge used in this page can be found here. In the future, this will most likely be contained within the hashconnect codebase for obvious reasons.

  1. as of v2.11.0 of the hedera-sdk-js, custom network definitions (such as local ones) are not supported.