UNPKG

@appliedblockchain/silentdatarollup-ethers-provider-fireblocks

Version:
78 lines (73 loc) 3.4 kB
import { BrowserProvider, Eip1193Provider, Networkish, BrowserProviderOptions } from 'ethers'; import { BaseConfig } from '@appliedblockchain/silentdatarollup-core'; declare const DEBUG_NAMESPACE_SILENTDATA_INTERCEPTOR = "fireblocks-web3-provider:silentdata-interceptor"; declare const EIP712Domain: { name: string; type: string; }[]; interface FireblocksProviderConfig extends BaseConfig { /** * When set to true, eth_call requests will be signed * with authentication headers, regardless of whether they match signable contracts */ alwaysSignEthCalls?: boolean; } declare class SilentDataRollupFireblocksProvider extends BrowserProvider { private lastNonce; private ethereum; private network; private _options; private config; private baseProvider; constructor({ ethereum, network, options, config, }: { ethereum: Eip1193Provider; network?: Networkish; options?: BrowserProviderOptions; config?: FireblocksProviderConfig; }); /** * Manages and returns the next available nonce for a given address. * * This method implements a local nonce management system to handle concurrent * transactions and potential network delays. It's necessary because: * 1. Multiple transactions can be initiated before earlier ones are confirmed. * 2. We need to ensure each transaction uses a unique, incrementing nonce. * * The method works by: * - Tracking the last used nonce for each address. * - Comparing it with the current network nonce. * - Always returning a nonce higher than both the network nonce and the last used nonce. * * This approach helps prevent nonce conflicts and ensures transactions can be * sent in rapid succession without waiting for network confirmation. * * @param address - The Ethereum address for which to get the next nonce. * @returns A Promise that resolves to the next available nonce as a number. */ private getNextNonce; /** * Custom method to handle transaction creation, signing, and broadcasting. * * This method is necessary because: * 1. When using Fireblocks to sign a transaction with CONTRACT_CALL, * Fireblocks also broadcasts the transaction to the specified chain * on the Fireblocks provider configuration. * 2. We need to manually handle the transaction creation process instead of * delegating everything to Fireblocks, as we need to broadcast it to our * own nodes. * 3. When populating a transaction (e.g., getting the nonce), we need to make * requests with auth headers to our RPC. * * This custom implementation allows us to control the entire process, * from transaction creation to signing and broadcasting. It ensures that * the necessary authenticated requests are made when populating the transaction, * and that the final transaction is broadcast to our specific nodes. * * @param payload - The transaction payload to be sent * @returns The transaction hash */ sendTransaction(payload: any): Promise<string | null>; private setupInterceptor; clone(): SilentDataRollupFireblocksProvider; } export { DEBUG_NAMESPACE_SILENTDATA_INTERCEPTOR, EIP712Domain, type FireblocksProviderConfig, SilentDataRollupFireblocksProvider };