@appliedblockchain/silentdatarollup-ethers-provider-fireblocks/dist/index.d.mts

Ethers.js provider for Silent Data [Rollup] with Fireblocks integration

import { BaseConfig } from '@appliedblockchain/silentdatarollup-core';
import { BrowserProvider, Eip1193Provider, Networkish, BrowserProviderOptions } from 'ethers';

declare const DEBUG_NAMESPACE_SILENTDATA_INTERCEPTOR = "fireblocks-web3-provider:silentdata-interceptor";

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?: BaseConfig;
    });
    /**
     * 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, SilentDataRollupFireblocksProvider };