Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] An Optimism Provider #48

Open
HrikB opened this issue Aug 26, 2024 · 2 comments
Open

[Feature] An Optimism Provider #48

HrikB opened this issue Aug 26, 2024 · 2 comments

Comments

@HrikB
Copy link
Contributor

HrikB commented Aug 26, 2024

Component

provider, pubsub

Describe the feature you would like

Add an alloy Provider for the Optimism network.

Additional context

No response

@emhane
Copy link
Collaborator

emhane commented Jan 8, 2025

lacking context what to do here exactly, do you have any links to reference impl @HrikB ?

@HrikB
Copy link
Contributor Author

HrikB commented Jan 9, 2025

I had something like this in a private repo

#[async_trait]
pub trait OpStackProvider<T: Transport + Clone = BoxTransport>: Provider<T, Optimism> {
    const ECOTONE_HARDFORK_BLOCK: u64;
    const ECOTONE_HARDFORK_BLOCK_TIMESTAMP: u64;

    async fn output_at_block(&self, block_number: u64) -> TransportResult<OutputAtBlock> {
        let response = self
            .client()
            .request("optimism_outputAtBlock", (format!("0x{:x}", block_number),))
            .await?;

        Ok(response)
    }
}

impl<T: Transport + Clone> OpStackProvider<T> for RootProvider<T, Optimism> {
    const ECOTONE_HARDFORK_BLOCK: u64 = 117387812;
    const ECOTONE_HARDFORK_BLOCK_TIMESTAMP: u64 = 1710374401;
}

But basically I think an OptimismProvider is needed with all the optimism specific rpc endpoints. For my usecase, I only needed output_at_block.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants