# Conduit Documentation

> Learn how to deploy your own rollup in minutes using Conduit's self-serve platform. No coding required - get enterprise-grade rollup infrastructure

# Powerful Chain Infrastructure

Conduit is the complete chain infrastructure platform where the best teams in crypto scale their apps and ecosystems. On Conduit, teams can effortlessly customize and deploy their chains with the latest rollup technologies like OP Succinct and G2, the world's most powerful sequencer. Get all the tooling you need with built-in RPCs, Account Abstraction, and 70+ more apps in the Marketplace.

## Platform Overview

Customize and launch your own dedicated chain in minutes.

Use API keys to access unrestricted RPC endpoints.

## Talk to Conduit

> Frequently asked questions about Conduit

# Frequently Asked Questions

***

#### What kinds of teams use Conduit?

Any team building high-performance applications onchain. We support use cases across DeFi, TradFi, DEXs, RWAs, stablecoins, gaming, consumer apps, AI, and beyond. See some of our customers here.

***

#### My app works fine running on another chain, why do I need my own?

Applications often start strong on shared chains but inevitably hit scaling limits – high fees, latency, and congestion – as they compete for blockspace. A dedicated chain solves these challenges, enables full customization for your exact needs, and transforms gas fees from overhead into revenue.

***

#### I want my own chain. Should I build a rollup or custom L1?

It depends on your goals. Conduit supports both rollups and custom L1s, and we work closely with every team to choose the right architecture. Whether you need Ethereum alignment, full sovereignty, or a hybrid solution, we provide the infrastructure and expertise to launch the best version of your chain.

***

#### Why should I launch my chain with Conduit rather than build it myself?

Building a chain in-house comes with significant costs – months of work, millions in engineering costs, and coordination between many third parties (rollup frameworks, DA providers, interoperability, etc.). Ongoing maintenance, troubleshooting, and upgrade implementations add further strain post-launch. Conduit covers all of this seamlessly, starting at just \$36K/year, freeing you to focus entirely on your business.

***

#### Do I own my chain if I launch it with Conduit?

Yes. If you need to take control of your chain or want to migrate to a different hosting platform, we’ll send the necessary keys to a wallet of your specification as soon as you ask. This is standard in our contracts. If you need our help migrating, we can do that too.

***

#### Does Conduit offer support?

Absolutely. Every Conduit customer gets a dedicated SLA, with options up to \<1-hour response times and direct access to our engineering team. Beyond technical support, we partner strategically to optimize your chain, advise on integrations, fine-tune your GTM strategy, and ensure your long-term success. Learn more about our support plans.

***

#### What's the difference between a discoverable and hidden chain?

When your chain is set as discoverable it's displayed in the Conduit app to other users. This means that it's published on pages such as [Nodes](https://app.conduit.xyz/nodes), which anyone with a Conduit account outside of your organization can access. Also, a [public URL](https://app.conduit.xyz/published/view/zora-mainnet-0) is generated for your chain where its network information and tooling can be found.

All chains are set as hidden by default. Hidden rollups are not discoverable or visible anywhere in the Conduit app except to your own organization. However, it still remains a live, publicly viewable blockchain.

***

#### What's a verified chain?

Since chain deployment is permissionless and their names, icons, or IDs aren't always unique, we've introduced a small feature in the UI which we call verification. All that means is that we have manually verified the chain and its owner are authentic. Anyone can request us to verify their chain by [submitting a request](https://conduitxyz.typeform.com/to/UYTp17YT). We typically only verify popular chains in an effort to protect people from malicious chains imitating legitimate chains (we've yet to see this happen but verification is there as a precaution).

***

#### How do I cancel a testnet or mainnet subscription plan?

Deleting your testnet or mainnet rollup automatically cancels the subscription associated with that deployment. You can delete your rollup from Settings > General in your deployment dashboard.

***

#### Why do I see a "This is a potential scam" warning when adding my network to MetaMask?

MetaMask shows this warning when a network's ChainID isn't recognized or verified. MetaMask pulls ChainIDs from a community-maintained repository on GitHub: [Ethereum-Lists](https://github.com/ethereum-lists/chains). To resolve this, you can submit a PR to add your network's ChainID to the list.

***

#### Why did my transaction fail with "oversized data" error?

Transactions can fail if they exceed the maximum allowed size (128KB). This limit exists because large transactions are more expensive to process and harder to propagate across the network. This commonly occurs when batch minting/purchasing multiple NFTs or making complex smart contract interactions with large calldata.

If you encounter this error, you can resolve it by breaking your transaction into smaller batches or reducing the number of items per transaction.

For reference, transactions are limited to 128KB by the `txMaxSize` parameter in [Geth based nodes](https://github.com/ethereum/go-ethereum/blob/master/core/txpool/legacypool/legacypool.go#L52-L56).

> Add a team domain to Conduit to auto-add teammates who have a matching email domain when they register for Conduit

# Adding Teammates

Visit the [Conduit app](https://app.conduit.xyz).

Add a team domain that will auto-add teammates who have a matching email domain when they register for Conduit. Or invite members directly by adding their email addresses.

> Learn how to configure two-factor authentication for your account

# Configuring Two-factor Authentication

Enabling two-factor authentication (2FA) for your account adds an extra layer of security when logging into your accounts.

> **Note:** If you lose access to your two-factor authentication app, you will need to contact our support to re-gain access to your account.

## Steps

To enroll in Two-factor authentication, a time-based one-time password (TOTP) application generates a code that will change after a certain amount of time. Conduit suggests using two applications during enrollment if the application you wish to use does not support cloud-based backup in case of device loss.

> **Tip**: To setup two-factor authentication on multiple devices, during setup, scan the QR code using each device or application at the same time. You can also copy the "Authenticator setup key", which is the TOTP secret. If you wish to change your Two-factor authentication device, you must un-enroll your first device before adding a new one.

1. Download a time-based one-time password (TOTP) app to your phone or desktop. Most password managers have this feature built-in.

2. In the upper-right corner of any page, click your name, then click **Account Settings**

   ![Account Settings](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/be32b45d31182f5086e3852e6bd0684e137c3c451e318cd64b64fb727b6404f8/docs/pages/support/account-settings.png)

3. In the "Two-factor authentication" section of the page, click **Add**.
   If you have been logged in for some-time you will need to log back in again to enable Two-factor authentication, we will redirect you back here once you log back in.

4. Under "Scan the QR code", do one of the following:

   * Scan the QR code with your authentication app. Once scanned, the app will show a six-digit code for you to enter.
   * If you're unable to scan the QR code, the "Authenticator setup key" can be used to setup your TOTP account manually.

   ![Setup 2FA](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/5e862b20b3c4d42216608dc7fc152788d988bbb8104c6e5e842ddb9f257b1624/docs/pages/support/setup-2fa.png)

5. Your TOTP application will save your account on conduit.xyz and will generate an authentication code every few seconds. Back in Conduit, type the authentication code into the field under "Verify the code from the app".

## Manually configuring a TOTP app

If you cannot scan the setup QR code or would like to setup your authentication app manually, the required information is:

```txt
Type: TOTP
Label: Conduit:<email> where <email> is the email you sign into Conduit with
Secret: This is the encoded setup key, visible below "Authenticator setup key" during enrollment
Issuer: conduit.xyz
Algorithm: The default of SHA1 is used
Digits: The default of 6 is used
Period: The default of 30 (seconds) is used
```

> Detailed list of available actions in the Conduit app.

# Roles & Permissions

Use this page to understand what different roles can (and can't) do in the Conduit app. This helps you assign the right access to your team — so everyone can do their job without stepping on toes.

## Roles

There are currently three roles in Conduit:

* **Admin** → full access to everything
* **Member** → can build and manage, but not change team settings
* **Viewer** → can view data but not make changes

You can check your role by going to **Settings → Team** in the [Conduit
app](https://app.conduit.xyz)

## Permissions

✅ = Allowed ❌ = Not allowed

### Team Management

Manage who's in your organization, what they can do, and how they join.

| Action                        | Admin | Member | Viewer |
| ----------------------------- | ----- | ------ | ------ |
| See part of your organization | ✅     | ✅      | ✅      |
| Invite a new team member      | ✅     | ✅      | ❌      |
| Add verified email domain     | ✅     | ✅      | ❌      |
| Leave the organization        | ✅     | ✅      | ❌      |
| Change organization settings  | ✅     | ❌      | ❌      |
| Change a team members role    | ✅     | ❌      | ❌      |
| Remove a team member          | ✅     | ❌      | ❌      |
| Cancel an invite              | ✅     | ❌      | ❌      |
| Update organization contacts  | ✅     | ❌      | ❌      |
| Update organization name      | ✅     | ❌      | ❌      |

### Customizations

Setup and adjust customizations including custom domains.

| Action                                     | Admin | Member | Viewer |
| ------------------------------------------ | ----- | ------ | ------ |
| Add a custom domain (like yourcompany.com) | ✅     | ❌      | ❌      |
| Remove a custom domain                     | ✅     | ❌      | ❌      |

### Billing & Plans

Access billing settings, update your subscription, or view pricing details.

| Action                        | Admin | Member | Viewer |
| ----------------------------- | :---: | :----: | :----: |
| View current subscriptions    |   ✅   |    ✅   |    ✅   |
| Access billing settings       |   ✅   |    ✅   |    ❌   |
| Choose a plan or make changes |   ✅   |    ✅   |    ❌   |

### API Key Management

Create and manage API keys used to connect to your networks securely.

| Action                               | Admin | Member | Viewer |
| ------------------------------------ | :---: | :----: | :----: |
| View existing keys and limits        |   ✅   |    ✅   |    ✅   |
| Create, update, or delete an API key |   ✅   |    ✅   |    ❌   |
| Set limits on API usage              |   ✅   |    ❌   |    ❌   |

### Network Management

Create, configure, and protect your networks from accidental changes.

| Action                              | Admin | Member | Viewer |
| ----------------------------------- | :---: | :----: | :----: |
| View network activity and usage     |   ✅   |    ✅   |    ✅   |
| Create, update, or delete a network |   ✅   |    ✅   |    ❌   |
| Activate deletion protection        |   ✅   |    ❌   |    ❌   |

> Manage your billing details and view invoices within Conduit

# Billing & Invoices

This guide will walk you through managing your billing details and viewing invoices within Conduit, providing seamless access to your billing information.

Log in to the [Conduit app](https://app.conduit.xyz).

Click `Billing` in the sidebar navigation.

You will be redirected to Stripe, where you can view your active subscriptions, manage your billing details, and access past invoices.

> Customers like Aevo, Zora, Mode, and more have already deployed with Conduit

# Chains

Customers like Polygon, Ethena, Plume, Blackbird, and more have already deployed with Conduit. We work closely with Optimism on the Superchain, Arbitrum on Orbit, and Polygon on AggLayer.

* Build on production-ready stacks from Optimism, Arbitrum, and Polygon
* Go modular by choosing your ideal settlement and data availability layers
* Customise your chain to the needs of your project and its users

Launch a testnet rollup from the Conduit app.

Schedule a call with our sales team.

View our chain pricing plans.

> Deploying your own L2 or L3 testnet with Conduit is quick and easy

# Deploy a Testnet Rollup

Deploying your own L2 or L3 testnet with Conduit is quick and easy. It only takes a few minutes through the Conduit app, no code required.

## Steps

Go to the [Conduit app](https://app.conduit.xyz).

We charge a monthly fee per deployment. You can cancel anytime by deleting your chain.

**Need some guidance?** [Contact us](https://portal.usepylon.com/conduit-xyz/forms/support-request) or [schedule a demo](https://conduitxyz.typeform.com/to/v0WGo3cz).

> Complete guide to setting up and running an OP Stack node on Conduit. Learn how to configure settings, gather required information, and set up external nodes for self-hosting.

# Run an OP Stack Node

At this time, the setup and maintenance of self-hosted nodes are not included in Conduit’s standard scope of support. The guide below provides a high-level overview for setting up an external node. Please note that, due to frequent updates to the underlying software, additional configuration steps or variables may be required.

If you’re onboarding a partner or tool, we recommend using [Conduit Nodes](https://conduit.xyz/nodes) — the managed, production-ready version of nodes for your RPC needs. Conduit RPC nodes are actively maintained, monitored, and optimized to scale with your network’s performance requirements.

If you’d like to maintain a backup RPC provider, we suggest [Tenderly](https://tenderly.co/), an approved Conduit vendor.

To run a self-hosted node for an OP Stack rollup deployed on Conduit, please follow the steps below to configure the necessary settings and gather all required information. Afterwards, you can proceed with [Conduit's Github Repository](https://github.com/conduitxyz/conduit-optimism-external-node) on how to run a node.

Log in to the [Conduit app](https://app.conduit.xyz).

Navigate to your deployment dashboard. Click on `Settings`, then select `General` from the sidebar.

Activate the `Enable external nodes` setting. **Note**: If you wish to disable this setting later, please contact our [Support](https://portal.usepylon.com/conduit-xyz/forms/support-request).

Navigate to the Deployment Dashboard. Go to the `Overview` section and click the `Run a Node` button on the right side.

OR

Visit the [Conduit Hub](https://hub.conduit.xyz/) if the network is public, select the network and click on `Run a Node`.

#### Access configuration files

The popup will provide the `rollup.json`, `genesis.json` files and other required parameters.

You should now have all the information about your Rollup that is needed to run your own self-hosted node. Follow [Conduit's Repository](https://github.com/conduitxyz/conduit-optimism-external-node) for the next Steps.

### Replica Configuration and Monitoring

#### P2P configuration

You will find the value for `OP_NODE_P2P_STATIC` in the same popup. We also recommend setting [`OP_NODE_P2P_SYNC_ONLYREQTOSTATIC`](https://docs.optimism.io/operators/node-operators/configuration/consensus-config#p2psynconlyreqtostatic) to `true`. This setting ensures more consistent and stable synchronization by forcing the node to request sync data only from `OP_NODE_P2P_STATIC`.

#### Submitting transactions to your node (if required)

If you plan to submit transactions to your node, set the `public RPC URL` of your network as the `OP_GETH_SEQUENCER_HTTP`. For production usage, you can generate an API Key via [Conduit Nodes](https://conduit.xyz/nodes). You can find the `public RPC URL` in the dashboard or on the hub.

#### Monitoring Sync Progress

Run [optimism\_syncStatus](https://docs.optimism.io/node-operators/reference/op-node-json-rpc#optimism-syncstatus) to check the current sync status of your node. From the output, note the block number associated with the sync status. Search for this block number on your block explorer to determine when it was processed on our end. By comparing the block’s processing time, you can estimate how far behind your node is in the synchronization process.

> Complete guide to setting up and running an Arbitrum Orbit node on Conduit. Learn how to configure settings, gather required information, and set up external nodes for self-hosting.

# Run an Arbitrum Orbit Node

At this time, the setup and maintenance of self-hosted nodes are not included in Conduit’s standard scope of support. The guide below provides a high-level overview for setting up an external node. Please note that, due to frequent updates to the underlying software, additional configuration steps or variables may be required.

If you’re onboarding a partner or tool, we recommend using [Conduit Nodes](https://conduit.xyz/nodes) — the managed, production-ready version of nodes for your RPC needs. Conduit RPC nodes are actively maintained, monitored, and optimized to scale with your network’s performance requirements.

If you’d like to maintain a backup RPC provider, we suggest [Tenderly](https://tenderly.co/), an approved Conduit vendor.

To run a self-hosted node for an Arbitrum rollup deployed on Conduit, please follow the steps below to configure the necessary settings and gather all required information. Afterwards, you can proceed with [Conduit's Github Repository](https://github.com/conduitxyz/conduit-arbitrum-external-node) on how to run a node.

Log in to the [Conduit app](https://app.conduit.xyz).

Navigate to your deployment dashboard. Click on `Settings`, then select `General` from the sidebar.

Activate the `Enable external nodes` setting. **Note**: If you wish to disable this setting later, please contact our [Support](https://portal.usepylon.com/conduit-xyz/forms/support-request).

Navigate to the Deployment Dashboard. Go to the `Overview` section and click the `Run a Node` button on the right side.

OR

Visit the [Conduit Hub](https://hub.conduit.xyz/) if the network is public, select the network and click on `Run a Node`.

#### Access configuration files

You will find the `Websocket URL` for the `Sequencer Feed Relay` and `HTTP URL` for the `AnyTrust DA (Fallback)` and other required parameters in the same popup.

You should now have all the information about your Rollup that is needed to run your own self-hosted node. Follow [Conduit's Repository](https://github.com/conduitxyz/conduit-arbitrum-external-node) for the next Steps.

> OP Stack is the premiere open-source rollup implementation

# OP Stack

> Conduit allows you to launch a rollup in a fraction of the time with the OP Stack.

OP Stack is the premiere open-source rollup implementation. You get:

* **10-100x cheaper fees** than Ethereum Mainnet
* **Interoperability** with Mainnet through trustless bridging
* **Ethereum Equivalence**, so you can use the same workflows and tooling
* Improved node performance, so you can get **thousands of transactions per second**

Below is a great primer on how the OP Stack works to bring you more performance while maintaining security:
[(Almost) Everything you need to know about Optimistic Rollup](https://www.paradigm.xyz/2021/01/almost-everything-you-need-to-know-about-optimistic-rollup)

## Supported JSON RPC Methods

`op-geth` implements the same methods as `go-ethereum`, With minimal changes compared to the upstream geth methods, The supported JSON RPC methods can be found [here](https://docs.optimism.io/builders/node-operators/json-rpc#op-geth)

## FAQ

### How do I withdraw/bridge tokens?

Please see our guide of using the Conduit SDK alongside the Optimism SDK [here](https://github.com/conduitxyz/optimism-tutorial/tree/main/cross-dom-bridge-eth).

### Are there any public audits?

Optimism audits can be found [here](https://github.com/ethereum-optimism/optimism/tree/develop/docs/security-reviews). Optimism has a [security model](https://docs.optimism.io/stack/security/faq-sec-model) to support the continuous development they do time by time.

For Celestia based op rollups, you can find the audit [here](https://docs.celestia.org/audits/Celestia_OP_Stack_Audit.pdf).

### Will my rollup come with any pre-deployed contracts or preinstalls?

Yes, when launching a rollup on the OP Stack, several core contracts come preinstalled, allowing you to move to production faster. These pre-deployed contracts include `Safe`, `SafeL2`, `Multicall3`, `MultiSend`, `MultiSendCallOnly`, `create2` Proxy, `create2deployer`, Safe Singleton Factory, `permit2`, ERC-4337 Entrypoint `v0.6.0`. For more details, visit the official [Optimism documentation](https://docs.optimism.io/builders/chain-operators/features/preinstalls).

> Arbitrum Nitro is the one of the premier rollup implementations on Ethereum

# Arbitrum Nitro

> Conduit allows you to launch a rollup in a fraction of the time with Arbitrum Nitro (often referred to as Arbitrum Orbit when referencing rollups).

Arbitrum Nitro is the one of the premiere rollup implementations on Ethereum. Their technology boasts the usual benefits of rollups, like dedicated compute for your application, in addition to:

* **10-100x cheaper fees** than Ethereum Mainnet (go even cheaper with [data availability committee support](https://docs.arbitrum.io/inside-anytrust))
* **Interoperability** with Mainnet through trustless bridging and fraud proofs
* **Close** **Ethereum Compatibility**, so you can use the same workflows and tooling
* **[Stylus](https://medium.com/offchainlabs/hello-stylus-6b18fecc3a22)**, which will allow you to write smart contracts in a more performant VM with Rust, C++, or other languages that can compile to WASM. These contracts can interoperate synchronously with the EVM.

## Supported JSON RPC Methods

Arbitrum implements the same JSON RPC methods supported by `go-ethereum` with minimal changes to their upstream geth methods. The supported JSON RPC methods can be found [here](https://docs.arbitrum.io/build-decentralized-apps/arbitrum-vs-ethereum/rpc-methods).

## FAQ

### How do I withdraw/bridge tokens?

Please see our guide and use of the arbitrum sdk [here](https://github.com/conduitxyz/arbitrum-tutorial).

### Does Arbitrum on Conduit support Stylus?

Arbitrum Stylus is enabled by default for new Conduit Rollups. If you're unsure whether Stylus is active on your rollup, please reach out to our [Support Team](mailto:support@conduit.xyz).
Please also see the excellent arbitrum stylus docs [here](https://docs.arbitrum.io/stylus/stylus-gentle-introduction).

### How do I enable fast withdrawals on my Orbit chain?

Fast withdrawals can reduce withdrawal times from multiple days down to as quick as 15 minutes. To enable fast withdrawals on your Orbit chain, please reach out to our [Support Team](mailto:support@conduit.xyz) who can help configure your withdrawal settings that best suit your needs.

For detailed technical documentation on fast withdrawals, visit the [Arbitrum docs](https://docs.arbitrum.io/launch-orbit-chain/how-tos/fast-withdrawals).

### How do I deploy Stylus Contracts to my Arbitrum Orbit stack?

If Stylus is not yet enabled on your rollup, follow Arbitrum’s [hello world guide](https://github.com/OffchainLabs/stylus-hello-world). You’ll then be able to deploy to your stack with:

```bash
cargo stylus deploy --endpoint=https://nitrorpc-[your_conduit_stack_name-here].t.conduit.xyz --private-key=[your_private_key_here]
```

### Are there any public audits?

Arbitrum audits can be found [here](https://docs.arbitrum.io/audit-reports).

For Celestia based Nitro rollups, you can find the audit [here](https://github.com/celestiaorg/nitro/blob/celestia-v2.3.3/audits/celestia/arbitrum_nitro_celestia_audit_report.pdf).

### Why does my block explorer show a gas limit of `1,125,899,906,842,624` instead of the expected 32 million?

The gas limit shown on an Arbitrum block is an artificially large number (1,125,899,906,842,624) and represents the maximum theoretical gas limit to account for variations in Layer 1 (L1) data posting costs. This value allows for flexibility in L1 transaction costs but does not reflect the actual execution capacity of the block. In practice, the effective gas limit for transaction execution on Arbitrum is capped at 32 million gas per block. You can find more details on this in the [Arbitrum documentation](https://docs.arbitrum.io/build-decentralized-apps/arbitrum-vs-ethereum/block-numbers-and-time#:~:text=To%20accommodate%20potential%20variations%20in,is%20capped%20at%2032%20million).

> Launch an Agglayer-connected ZK rollup with Conduit.

# Agglayer CDK

For detailed protocol documentation, refer to the official <a href="https://docs.agglayer.dev/" target="_blank">Agglayer docs</a>.

> Conduit allows you to launch a ZK-powered OP Stack rollup in a fraction of the time using Agglayer CDK.

Agglayer CDK is a Polygon-powered L2 framework that combines **OP Stack architecture with ZK validity proofs**, enabling faster finality and native cross-chain interoperability via Agglayer.

You get full EVM compatibility, familiar tooling, and access to Agglayer’s shared liquidity ecosystem.

***

## Supported JSON RPC Methods

Agglayer CDK uses `op-geth`, which maintains compatibility with standard go-ethereum (geth) JSON-RPC methods.
The supported JSON RPC methods can be found [here](https://docs.optimism.io/node-operators/reference/op-geth-json-rpc#op-geth-json-rpc-api)

***

## Key Advantages

### Faster Finality

ZK validity proofs enable significantly faster withdrawals than traditional optimistic challenge periods.

* Deposits: \~2 minutes (configurable)
* Withdrawals: \~1 hour minimum (configurable based on cost vs security)

### Native Agglayer Interoperability

Chains connect to the **Agglayer Unified Bridge**, enabling:

* Shared liquidity across connected chains
* Cross-chain messaging
* Programmable bridging via Polygon SDKs

Conduit also provides a hosted bridge UI out of the box.

### Familiar OP Stack Architecture

* EVM equivalent
* Standard Ethereum tooling (Hardhat, Foundry, ethers, etc.)
* Compatible with existing OP Stack infra patterns

No new execution environment to learn.

### Battle-Tested ZK Infrastructure

The ZK proving system is already running in production.

Conduit currently operates this stack for:

* Katana
* Phala

***

## FAQ

### Is this a new stack?

Not entirely.

Agglayer CDK builds on OP Stack architecture, adding ZK validity proofs and interoperability via Agglayer.

If you’re familiar with OP Stack, the development experience remains the same.

### Does it support alt-DA?

Yes. Agglayer-connected chains can be deployed using the OP Succinct stack, which supports:

* Ethereum blobs
* Celestia
* EigenDA

Celestia and EigenDA support within OP Succinct are currently marked as [experimental](https://succinctlabs.github.io/op-succinct/fault_proofs/experimental/experimental.html)

### How does bridging work?

Conduit provides:

* Hosted bridge UI
* Unified Bridge integration
* SDK-based programmable bridging via Polygon tooling

Users can bridge across the Agglayer ecosystem once connected.

### What are the average deposit and withdrawal times?

Times depend on configuration and security parameters:

* Deposits: typically \~2 minutes
* Withdrawals: \~1 hour minimum

These can be tuned depending on cost vs finality requirements.

### Is the ZK system audited?

Yes. The underlying components have undergone public security reviews.

* Optimism (OP Stack) : [audit report](https://github.com/ethereum-optimism/optimism/tree/develop/docs/security-reviews#security-reviews)
* Succinct (OP Succinct) : [audit report](https://github.com/succinctlabs/succinctx/blob/main/audits/Curta_Plonky2x_Audit_Report_KALOS.md)
* Agglayer contracts : [audit report](http://github.com/agglayer/agglayer-contracts/tree/v12.2.2/audits)

***

# Case Study

How Conduit Embedded with Polygon Labs to Build the Katana L2 Chain

# Brand Customization

> Learn how to customize your rollup's branding. Configure display names, logos, brand colors, and social media metadata through the Conduit dashboard.

## Customization options- Chain display name (e.g. Zora Network)
  * Appears:
    * In your block explorer homepage header and tab title
    * In the Conduit app – under Nodes, Hub, and your own dashboard
- Logo and icon (light mode and dark mode)
  * Appears:
    * In your block explorer sidebar
    * In the Conduit app – under Nodes, Hub, and your own dashboard
- Primary brand color
  * Appears:
    * In your block explorer homepage header
- Meta image
  * Appears:
    * In your block explorer link when shared on social media
- Meta description
  * Appears:
    * In your block explorer link when shared on social media## StepsGo to the [Conduit app](https://app.conduit.xyz) and sign in.Please note that customizations can take 2-5 mins to appear.## Discoverable chains and verified statusTo display your chain on the [Conduit Hub](https://hub.conduit.xyz) and to show up on the Conduit Nodes Endpoints list you can set your chain's Discoverability settings to **Discoverable**.Once your chain is set to discoverable, request verification for your chain from the Conduit team after you customize the above settings and your organization has been verified.### StepsGo to the [Conduit app](https://app.conduit.xyz) and sign in.This will mark your chain as discoverable and will display it on the [Conduit Hub](https://hub.conduit.xyz) and in Conduit Nodes.![Verify Chain](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/b766924c19ebeb19233ffc91f539a96c6167c2a5016b54f2c7e3aac419363dc2/docs/pages/guides/verify-chain.png)Verification can take some time.

> Learn how to set up custom domains for your Conduit RPC and block explorer.

# Custom Domains

Easily configure your Conduit RPC and block explorer to be accessible through a **custom domain**.

## Steps

Log in to the [Conduit app](https://app.conduit.xyz).

Navigate to your deployment dashboard. Click `Settings`, and then select `Customization` from the sidebar. Scroll down to the `Custom Domains` section.

Enter your custom domain for your Conduit RPC and/or Blockscout explorer.

Add the provided CNAME record to your domain's DNS settings. You can typically do this in your hosting provider's control panel. Note that DNS resolution may take up to 24 hours, depending on your provider.

If you're using Cloudflare, ensure that proxying is disabled for the subdomain you're setting up.

![Cloudflare](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/05fc77c1d672b6f08003d372af7735b83853b30534ddf00a000a3cbcfbf3149f/docs/pages/guides/cloudflare-proxying.png)

After DNS propagation is complete, you can start using your custom Conduit RPC URL or access your block explorer directly through your personalized domain.

> Guide for obtaining Sepolia (testnet) ETH through various faucets and bridging it to your Conduit chain, with steps covering faucet options and using the bridge interface through the Conduit dashboard.

# Get Testnet ETH

To get Sepolia (testnet) ETH on your chain, you'll need to acquire some from a faucet then bridge them over.

## Steps

First, head to your rollup's dashboard in the [Conduit app](https://app.conduit.xyz/). On the right sidebar of the dashboard below the Tracer we have a built-in faucet for Sepolia ETH.

![Sepolia Faucet](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/6dac1db56d0c1e10ae8b846678f2d6f1ab521db9783c5546583943ae60cfce99/docs/pages/guides/conduit-dashboard-faucet.png)

Or, head to the public [Conduit Faucet](https://faucet.conduit.xyz) *(requires GitHub sign in)* directly to get Sepolia ETH.

If you need more Sepolia ETH, here are some other recommended faucets:

* [Superchain Faucet](https://app.optimism.io/faucet) *(requires Privy sign in)*
* [Paradigm MultiFaucet](https://faucet.paradigm.xyz/) *(requires Twitter sign in)*

Enter your wallet address and begin receiving funds from your chosen faucet(s).

Once received, head to your deployment dashboard in the [Conduit app](https://app.conduit.xyz/).

Add your chain to your wallet's list of networks and ensure it's selected.

Head to your chain's bridge and move your Sepolia ETH from the Ethereum Sepolia network to your new chain.

If you haven't created a bridge yet, [follow this guide](https://docs.conduit.xyz/guides/bridge-ui).

> Set up a bridge UI for your Conduit rollup using Superbridge or open-source alternatives. Learn how to enable asset transfers between chains with step-by-step setup instructions.

# Bridge UIs

Bridge UIs are interfaces that enable users to transfer assets between different blockchain networks. By simplifying complex cross-chain transactions, these UIs make it easier for users to access services across multiple chains.

Conduit provides these bridge implementations as a resource, but we do not
take any responsibility for their functionality or security. Users should
evaluate them independently to ensure they meet their needs.

## Launch a Bridge UI powered by Superbridge.app

Superbridge makes it simple to launch a dedicated bridge UI for Conduit rollups. It is free for Conduit Testnet Rollups and pricing starts at \$1,000 per month for mainnet deployments, with a 50% discount available for projects that are part of the Optimism Superchain.

If you're ready to set up a **Mainnet** Superbridge, simply visit [Superbridge.app](https://dashboard.superbridge.app/register) and complete their self-serve signup process.

For **Testnet** setup, follow the steps outlined below.

Log into the [Conduit app](https://app.conduit.xyz) with your credentials.

Navigate to your Rollup’s deployment dashboard.

On the right side of the dashboard, click `Bridge Assets` and then select `Create Bridge`.

Once created, a link will appear to redirect you to the Bridge UI. From here, you can start depositing assets into your Rollup.

### Additional Resources

For more information, please explore the following:

* [Superbridge Overview](https://about.superbridge.app/rollies)
* [Superbridge Documentation](https://docs.superbridge.app/)

If you have any questions, feel free to reach out to [our support team](mailto:support@conduit.xyz) or contact the [Superbridge team](mailto:support@superbridge.app) directly.

## Open-source OP Stack Bridge UIs

* [github.com/nitantchhajed/op-stack-bridge](https://github.com/nitantchhajed/op-stack-bridge)

# Bridge CGT to Your Rollup (Arbitrum)

> Bridge the CGT ERC20 token from Ethereum to your Arbitrum rollup by calling the Inbox directly—either programmatically via command line or through etherscan—with step-by-step instructions and screenshots.

This guide walks you through depositing the CGT token from Ethereum (L1) to your Arbitrum rollup (L2).

## Prerequisites

* **L1 RPC URL** (for example, Ethereum Sepolia)
* **Private key** with enough ETH for gas on L1
* `TOKEN_ADDRESS`: CGT token address on L1
* `INBOX_ADDRESS`: Find this on the rollup contracts page as the "Inbox" or fetch it from [api.conduit.xyz/file/v1/arbitrum/core/your-network-slug](https://api.conduit.xyz/file/v1/arbitrum/core/your-network-slug)

Only CGT rollups exposes ERC20 deposit functions directly on the Inbox.

## Option A: Direct deposit via Inbox programmatically

Deposit CGT by calling your rollup's `Inbox` contract directly from the command line.

Approve the `INBOX_ADDRESS` as a spender for the amount you plan to deposit.

```bash
cast send "$TOKEN_ADDRESS" "approve(address,uint256)" "$INBOX_ADDRESS" "$RAW_AMOUNT" \
  --private-key "$PRIVATE_KEY" --rpc-url "$L1_RPC_URL"
```

Call the deposit function exposed by your rollup's Inbox implementation. The signature may vary; a common pattern is `depositERC20(address,uint256)`.

```bash
cast send "$INBOX_ADDRESS" "depositERC20(address,uint256)" "$TOKEN_ADDRESS" "$RAW_AMOUNT" \
  --private-key "$PRIVATE_KEY" --rpc-url "$L1_RPC_URL"
```

## Option B: Direct deposit via inbox on Etherscan

Use Etherscan to approve and deposit without writing code.

1. Open your CGT token on Etherscan (L1), go to `Contract` → `Write Contract`.
2. Connect your wallet with `Connect to Web3`.
3. Find `approve` and set `spender` to your `INBOX_ADDRESS`, `amount` to the desired deposit amount (in wei).

![Approve CGT on Etherscan](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/174f0d586b520426bd776661ea459449b04e7b2dccb07b783cc741e6a3f26a75/docs/pages/chains/guides/etherscan-erc20-approve.png)

1. Open the `INBOX_ADDRESS` on Etherscan, go to `Contract` → `Write Contract`.
2. Connect your wallet.
3. Call the Inbox deposit function. For many rollups, this is `depositERC20(address,uint256)` with parameters:

* `token`: `TOKEN_ADDRESS` (CGT on L1)
* `amount`: amount in wei

![Deposit via Inbox on Etherscan](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/5375b6d23b64cbf7d92666044b5ab29f8488c73809af916fd02b43e4fdf0189f/docs/pages/chains/guides/etherscan-inbox-deposit.png)

After the L1 transaction confirms, the rollup sequencer picks up the message and credits your L2 balance once the retryable ticket executes.

> How to trace transactions on your Conduit chain using Foundry's Cast tool and the openchain.xyz API.

# Tracing Transactions

Install [Foundry](https://github.com/foundry-rs/foundry).

Submit your signatures through the [openchain.xyz](http://openchain.xyz) API.

```bash
cast run --rpc-url=[your_rpc_url] [tx_hash]
```

> Instructions for verifying smart contracts on Blockscout, including the correct API URL format, verification command using Foundry, and troubleshooting guidance for CREATE2 deployments.

# Smart Contract Verification

Conduit comes with a Blockscout instance, and you can verify against it with the url:

```txt
https://explorer-[your_network_id].t.conduit.xyz/api\?
```

**Note:** See this [foundry issue](https://github.com/foundry-rs/foundry/issues/5160#issuecomment-1631555377) for why you need to include `\?`

```bash
forge verify-contract [address] [contract] --verifier=blockscout --verifier-url=https://explorer-[your_network_id].t.conduit.xyz/api\?
```

## FAQ

### Why is contract verification failing when I deploy using `CREATE2`, and how can I resolve it?

Deploying a contract with `CREATE2` generates a deterministic address through an internal transaction, ensuring the same address is created regardless of the deployment's origin. Internal indexing is highly resource-intensive. As a result, we've disabled internal transaction indexing in Blockscout, meaning contracts deployed via `CREATE2` won’t be automatically indexed.

To resolve this, simply visit the contract address after deployment. Blockscout will fetch the contract from the RPC, recognize it, and allow verification to proceed. If needed, we can enable internal transaction indexing, but this would involve discussing pricing implications due to increased costs associated with higher growth.

# Share Chain Info with Partners

Conduit chains have the ability to publish them to the [Conduit Hub](https://hub.conduit.xyz), a single page for people to discover chains run on Conduit. These pages contain useful information for your users to be able to use your chain in their own apps and (if enabled) bridge their funds to your chain.

Early in your chain, you may want to keep it private but still share key information with partners and beta-testers. A share link puts everything in one place.

Using a private share link you can share a link to a hidden Hub page only accessible by the generated URL, and revokable at any time.

The Hub share link pages are **inaccessible by search engines and will not be
indexed**.

## Creating a share link

Log in to the [Conduit app](https://app.conduit.xyz).

Navigate to the `Chains` page and select your chain, from the sidebar click `Settings` and look for the `Private share link` sub-section underneath `Discoverability`.

Click `Create share link` and you'll receive a unique URL you can share with people to access your rollup's information. I.E. `https://hub.conduit.xyz/share/bKpvca2XADvKs8eu7mqWC`.

![Create share link](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/370ef7029fe4af0971035ca01a8e3928ebad395a83a8d821b12e495077161365/docs/pages/guides/share-chain-info/private-link.png)

## Revoking a share link

Shared links can be revoked at any time and will prevent anyone with the link from accessing your rollup's information.

Log in to the [Conduit app](https://app.conduit.xyz).

Navigate to the `Chains` page and select your rollup, from the sidebar click `Settings` and look for the `Private share link` sub-section underneath `Discoverability`.

Click `Revoke` and the share link will be deleted and will no longer be accessible.

![Revoke share link](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/1e2725d85cfb02f38b531beaf51e2b4d35fb9cae1268852d2eb090d92518dd24/docs/pages/guides/share-chain-info/private-link-created.png)

> Learn how to configure your rollup's public RPC settings to manage access with rpc API key, and contract deployer address restrictions.

# Rollup Access Controls & Permissioning

Manage your rollup's public RPC by configuring permissions across different security dimensions. To manage these settings go to your **Rollup's Dashboard** → select **Settings** from the sidebar → and click the **Access controls** tab.

## Access Control Lists (ACLs)

### Restrict Access to API keys

Limit access to your public RPC by allowing requests only from specified API keys. The **API keys allowlist** can be enabled and disabled individually, when disabled the RPC can be accessed by all traffic, keyed and un-keyed.

![API keys](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/793c319c448973c4e011099a30a3834abea723aa0db07aeafda4952436ef836e/docs/pages/guides/rollup-permissioning/acl-api-keys.png)

### Lock-down the RPC

You can fully restrict access to your rollup by enabling the **API keys allowlist** with no set API key restrictions.

![API keys](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/7b824ba0a2206dbb445e79649ea7824e030144d45ab63ba0fbca76e7a7e48566/docs/pages/guides/rollup-permissioning/acl-api-keys-enabled-empty.png)

### Restrict Contract deploys to Addresses

Limit contract deployments on your rollup to specified addresses. The **Contract deployer allowlist** can be enabled and disabled individually, when disabled contracts can be deployed on the chain by all addresses.

![Addresses](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/4d9eca39ddfe0dec935ac66512206ef33034f9a1cf531802ef0e8521c82b937f/docs/pages/guides/rollup-permissioning/acl-contract-deployers.png)

### Bulk edits

Both sections allow for bulk edits by copying a csv format to your clipboard, and pasting into the first text field. Your CSV should follow the format:

```
3cUM8KDmD5qXUyi6M2oQo1Mr6epGomSNB,App Key
EuEqg9ERTH37copjKTmnXxs1d5YfGgfkK,Explorer Key
```

**Note:** Do not include a header in the CSV or that will also be pasted into the first input

# Indexing your chain

> Learn how to index your Conduit chain. Compare and choose between indexing partners, including Goldsky, The Graph, Dune, and Ormi.

Indexing transforms raw onchain data into structured, queryable datasets, so that your apps, dashboards, and analytics tools can access events, transactions, and state without scanning the chain themselves.

Conduit works with several indexing providers, so you can choose the option that best fits your use case, from managed subgraphs to SQL-based analytics. Browse the full list of integrations on the [Conduit Marketplace](https://www.conduit.xyz/marketplace).

## Recommended indexing partners

Indexing through subgraphs and real-time data pipelines. Goldsky's subgraphs handle reorgs and RPC failures automatically, and Mirror streams onchain data into your existing database.

Use Goldsky when you want managed subgraphs and real-time data streaming without operating your own infrastructure.

[Goldsky docs](https://docs.goldsky.com/introduction)

A decentralized protocol for organizing and accessing blockchain data. Build with subgraphs served by a global network of independent indexers.

Use The Graph when you want the original subgraph standard, censorship-resistant queries, and a large existing developer community.

[The Graph docs](https://thegraph.com/docs/en/)

A Web3 data analytics platform. Through Conduit's one-click integration, your chain's data becomes available on Dune in weeks, ready for SQL queries, dashboards, and ecosystem reporting.

Use Dune when you want SQL-based analytics, public dashboards, and ecosystem-wide visibility.

[Dune docs](https://docs.dune.com)

Petabyte-scale indexing and querying of onchain data with subgraph compatibility. Ormi can index your rollup directly or provide custom subgraphs to your ecosystem.

Use Ormi when you need indexing at large scale, with the option of custom subgraphs for builders on your chain.

[Ormi docs](https://docs.ormi.xyz/0xgraph)

## How to choose

* For managed subgraphs and streaming pipelines, start with [Goldsky](https://www.conduit.xyz/marketplace/goldsky-indexing).
* For the decentralized subgraph standard, use [The Graph](https://www.conduit.xyz/marketplace/the-graph).
* For analytics, SQL queries, and public dashboards, integrate with [Dune](https://www.conduit.xyz/marketplace/dune).
* For indexing at large scale with optional custom subgraphs, contact [Ormi](https://www.conduit.xyz/marketplace/ormi).

All of these partners work with chains deployed on Conduit and can index data using your Conduit [RPC nodes](/rpc-nodes/overview). For more options, see the [Conduit Marketplace](https://www.conduit.xyz/marketplace). To request integration with any of these partners, please [contact sales](https://conduitxyz.typeform.com/request-demo), or submit an integration request for your chain from the [Conduit App](https://app.conduit.xyz).

# Bridged USDC

The Bridged USDC integration adheres to Circle's [Bridged USDC Standard](https://www.circle.com/en/bridged-usdc) for deploying bridged USDC onto your rollup. This integration offers several key benefits:

* **Secure and Audited**: Leverages the same trusted and audited code that has been deployed across numerous mainnets.
* **Seamless Upgrade Path**: Allows for a smooth transition to native USDC at a later date, eliminating the need for time-consuming migrations and providing developers and users immediate access to native USDC when available.

In this section, you will also learn how to avoid liquidity fragmentation and ensure a streamlined transition to native USDC while bridging onto your rollup.

## Upgrade to Native USDC

If the official USDC bridge from the Conduit Marketplace is used, you and Circle have the option to agree to upgrade to a native version of USDC at a later date. Having native USDC available on your rollup has the following benefits:

* Issuance is handled by Circle, a regulated fintech
* Fully reserved and redeemable 1:1 for US Dollars, instead of being backed by USDC on your rollup’s settlement layer
* Becomes the “official” form of USDC for your rollup, reducing liquidity fragmentation
* USDC can be bridged to all supported blockchain networks that are integrated with CCTP directly without withdrawing to the settlement layer

Therefore, we recommend using the official USDC bridge integration instead of third-party offerings.

If you would like to migrate to native USDC, please reach out to our support.

## Bridged USDC Details

In the Conduit UI, navigate to the `Apps` section. Click on `Your Apps` and select `Bridged USDC`. After installation, you’ll find the contracts addresses in the `Installation Details`.

## Pricing

The installation of this integration for mainnets has a one-time fee of \$50.

## Testnet USDC

If you need testnet USDC, you can get 10 USDC from the official Circle [Faucet](https://faucet.circle.com/). If you require additional funds, please don't hesitate to reach out to support.

## Note for Arbitrum-Stacks

For Arbitrum mainnets, the integration isn't immediately active after installation. Our support team will reach out to confirm the bridge configuration.

## Note for OP-Stacks

### Update Bridge UIs and Contracts

When installing the Bridged USDC Integration from the Conduit Marketplace on your Rollup, it's important to avoid having USDC liquidity split across different bridges. This can happen if the same asset is bridged with multiple bridge contracts, creating different versions of the token on your rollup.

1. If you're using SuperBridge or another bridge provider, it's a good idea to contact their support to have your new USDC bridge address added to their UI.

2. After deploying your new USDC bridge, update any related contracts and user interfaces to ensure users are interacting with the correct bridge.

# Bridge USDC to your OP Stack Rollup

This guide will show you how to manually bridge USDC to your rollup using [Foundry](https://book.getfoundry.sh/getting-started/installation) CLI commands.

## Depositing

On the settlement layer, execute the following steps to bridge USDC to your rollup:

In the Conduit UI, navigate to the `Apps` section. Click on `Your Apps` and select `Bridged USDC`. You’ll find the `Installation Details` in the bottom-right corner, including contract addresses for:

* `Bridged USDC (Rollup)`
* `USDC (Settlement Layer)`
* `Bridge (Rollup)`
* `Bridge (Settlement Layer)`
* `Rollup Factory (Rollup)`

Export these addresses as environment variables:

```bash
export ROLLUP_USDC_TOKEN_ADDRESS=<Bridged USDC>
```

```bash
export ROLLUP_USDC_BRIDGE_ADDRESS=<Bridge (Rollup)>
```

```bash
export SETTLEMENT_USDC_BRIDGE_ADDRESS=<Bridge (Settlement Layer)>
```

Pick your settlement layer and export the Settlement USDC Token Address and the RPC URL as environment variables:

| Settlement Layer | SETTLEMENT\_USDC\_TOKEN\_ADDRESS             |
| ---------------- | -------------------------------------------- |
| Ethereum Mainnet | `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` |
| Sepolia Testnet  | `0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238` |
| Arbitrum         | `0xaf88d065e77c8cC2239327C5EDb3A432268e5831` |
| Arbitrum Sepolia | `0x75faf114eafb1BDbe2F0316DF893fd58CE46AA4d` |
| Base             | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` |
| Base Sepolia     | `0x036CbD53842c5426634e7929541eC2318f3dCF7e` |

```bash
export SETTLEMENT_USDC_TOKEN_ADDRESS=0x....
```

```bash
export SETTLEMENT_RPC_URL=https://...
```

We need to sign the transactions with a private key. Refer to [Foundry's Key Management Best Practices](https://book.getfoundry.sh/guides/best-practices?highlight=private#private-key-management) for production use.

The following steps will utilize the `--private-key` flag and the `$PRIVATE_KEY` environment variable. Set the environment variable with the following command:

```bash
export PRIVATE_KEY=...
```

If you're using a different method, replace `--private-key $PRIVATE_KEY` with the appropriate flag in the commands below.

Make sure your wallet is funded with the native token and USDC on the settlement layer. If you are bridging onto a Testnet you can claim some testnet USDC here: [Circle Testnet Faucet](https://faucet.circle.com/).

Set the amount you want to bridge

```bash
export AMOUNT=100
```

Approve the Optimism bridge contract on the settlement layer to transfer your USDC:

```bash
cast send $SETTLEMENT_USDC_TOKEN_ADDRESS "approve(address,uint256)" $SETTLEMENT_USDC_BRIDGE_ADDRESS $AMOUNT --rpc-url $SETTLEMENT_RPC_URL --private-key $PRIVATE_KEY
```

Bridge USDC to your rollup:

```bash
cast send $SETTLEMENT_USDC_BRIDGE_ADDRESS "sendMessage(address,uint256,uint32)" $(cast wallet address $PRIVATE_KEY) $AMOUNT 100000 --rpc-url $SETTLEMENT_RPC_URL --private-key $PRIVATE_KEY
```

## Withdrawing

After a few minutes, your deposit should be processed and available on your rollup. To withdraw USDC, follow these steps:

Approve the rollup bridge contract to transfer your USDC:

```bash
cast send $ROLLUP_USDC_TOKEN_ADDRESS "approve(address,uint256)" $ROLLUP_USDC_BRIDGE_ADDRESS $AMOUNT --rpc-url $ROLLUP_RPC_URL --private-key $PRIVATE_KEY
```

Send USDC from your rollup back to the Settlement Layer:

```bash
cast send $ROLLUP_USDC_BRIDGE_ADDRESS "sendMessage(address,uint256,uint32)" $(cast wallet address $PRIVATE_KEY) $AMOUNT 100000 --rpc-url $ROLLUP_RPC_URL --private-key $PRIVATE_KEY
```

## Learn More

For a detailed overview of how the USDC bridge functions on Optimism, you can find the official documentation and the repository here:

* [Optimism Docs - Bridged USDC Standard on the OP Stack](https://docs.optimism.io/builders/chain-operators/features/bridged-usdc-standard)
* [Repository - Bridged USDC Standard for the OP Stack](https://github.com/defi-wonderland/opUSDC)

# Bridge USDC to your Arbitrum Rollup

For Arbitrum mainnets, the integration isn't immediately active after
installation. Our support team will reach out to confirm the bridge
configuration.

## Steps

In the Conduit UI, navigate to the `Apps` section. Click on `Your Apps` and select `Bridged USDC`. You’ll find the `Installation Details` in the bottom-right corner, including contract addresses for:

* `Bridged USDC (Rollup)`
* `USDC (Settlement Layer)`
* `USDC Gateway (Rollup)`
* `USDC Gateway (Settlement Layer)`
* `Proxy Admin (Rollup)`
* `Proxy Admin (Settlement Layer)`
* `Master Minter (Rollup)`

To bridge your USDC, follow the official [Arbitrum Token Bridge documentation](https://docs.arbitrum.io/build-decentralized-apps/token-bridging/token-bridge-erc20#example-standard-arb-erc20-deposit-and-withdraw).

## Migrating Existing USDC Liquidity to Circle's USDC Standard

This guide applies only to USDC bridged in via the standard gateway. If your
USDC was bridged using third-party bridges such as LayerZero or Wormhole, it
cannot be easily migrated.

Users will need to migrate their existing liquidity manually. We’ve created a guide to help facilitate this process that you can share with them. To complete the migration, users will need access to your old Standard Gateway address. Follow these steps to locate it.

Log in to the [Conduit app](https://app.conduit.xyz).

In your deployment dashboard, go to the **Overview** section, and find `core.json` in the bottom right corner.

Within `core.json`, locate the `standardGateway`. Then, navigate to your Settlement Layer’s block explorer and check for the `counterpartGateway` under **Contract** -> **Read as Proxy**.

Share the `standardGateway` address with your users, along with the following guide: [User Guide: Migrating Existing USDC Liquidity to Circle's USDC Standard](https://docs.conduit.xyz/bridged-usdc/bridging-to-arbitrum-rollup/migrating-existing-usdc)

## Learn More

To gain a deeper understanding of how the USDC bridge operates, you can find the official documentation and repository here:

* [Arbitrum Docs - How to adopt the bridged USDC standard on your Orbit chain](https://docs.arbitrum.io/launch-orbit-chain/how-tos/usdc-standard-bridge)
* [Repository - USDC Bridge Deployment Scripts](https://github.com/OffchainLabs/token-bridge-contracts/tree/main/scripts/usdc-bridge-deployment)

> Learn how to migrate your USDC liquidity to Circle's USDC Standard on Arbitrum chains. Step-by-step guide covering approval, withdrawal process, transaction monitoring, and bridging completion.

# User Guide: Migrating Existing USDC Liquidity to Circle's USDC Standard

To migrate your existing USDC liquidity on an Arbitrum chain that has recently adopted the Bridged USDC Standard, follow the steps below.

Find the ERC-20 USDC contract and `approve` the 'StandardGateway' to spend the full amount of your USDC. Contact the Chain team if the address to the 'StandardGateway' was not provided.

Call the `outboundTransfer` function on the approved USDC contract with the following arguments:

* **\_l1Token**: The address of the USDC contract on the settlement layer.
* **\_to**: The address on the settlement layer where you want to withdraw the USDC.
* **\_amount**: The amount to withdraw (note: 1 USDC = `1000000` units).
* **\_data**: Leave this field empty.

#### Using BlockScout

You can initiate this transaction directly through BlockScout's UI, when navigating to the Standard Gateway Contract.

#### Using Foundry

Alternatively, use Foundry with the following `cast` command, replacing the placeholders with your specific details:

```bash
cast call $STANDARD_GATEWAY "outboundTransfer(address,address,uint256,uint256,uint256,bytes)" $L1_USDC_ADDRESS $YOUR_ADDRESS $AMOUNT_TO_WITHDRAW 0 0 0x --rpc-url $RPC_URL --private-key $PK
```

After processing the transaction, monitor the withdrawal status in the Superbridge UI. This interface will guide you through the proving and finalization stages.

Once the withdrawal is complete and your USDC is back on the settlement layer, use the Superbridge UI or other recommended bridging methods to bridge it back to your rollup.

Once the bridging process is complete, your USDC will appear as Bridged USDC (USDC.e) on the rollup.

> Guide on enabling and disabling the Blockscout block explorer for your Conduit rollup

# Blockscout

Conduit rollups come with the option to enable the Blockscout block explorer whenever you need it. You can turn it on at any time from the settings page.

## Enable Blockscout

Blockscout can be enabled at any time from the Settings page of your Rollup.

Log in to the [Conduit app](https://app.conduit.xyz).

Navigate to the `Rollups` page and select your rollup, from the sidebar click `Settings`. Scroll down to the `Block explorer` section.

Click the switch to enable Blockscout. It may take some time for Blockscout to be ready on your rollup.

![Enable Blockscout](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/e24054ffc81329f68ecb5e5ff834a1d8d802427b58536ab82fa2b5d2e8d87236/docs/pages/guides/block-explorers/enable-blockscout.png)

**Note:** Enabling Blockscout will require indexing your chain, which may take some time depending on the size of the state. If Blockscout seems to be taking unusually long to start, or if you encounter any issues, please [contact support](https://portal.usepylon.com/conduit-xyz/forms/support-request).

## Disable Blockscout

Blockscout can be disabled at any time if your chain no longer needs it or if you prefer to use an external block explorer. Disabling Blockscout helps reduce resource usage and keep your infrastructure lean.

Log in to the [Conduit app](https://app.conduit.xyz).

Navigate to the `Rollups` page and select your rollup, from the sidebar click `Settings`. Scroll down to the `Block explorer` section.

Click the switch to enable Blockscout. You will be prompted to confirm by typing `disable blockscout` in the dialog. It may take some time for Blockscout to fully spin down for your rollup.

![Disable Blockscout](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/9134348b22ca7052a8b906215322ac0093ee220de18b76d4fb33d1812bb1fdd3/docs/pages/guides/block-explorers/disable-blockscout.png)

![Disable Blockscout Dialog](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/e5cc5a7f942fdcb1cb116e4ec853604879fc515bfb446815492bd37b3e088ffa/docs/pages/guides/block-explorers/disable-blockscout-dialog.png)

**Note:** When Blockscout is disabled no data will be lost. A snapshot of the current state will be saved and when Blockscout is enabled again it will re-index the chain from where it left off. If anything seems wrong after re-enabling Blockscout [contact support](https://portal.usepylon.com/conduit-xyz/forms/support-request).

# Bundler

> Explore Conduit's Bundler, enabling advanced Account Abstraction features with ZeroDev, Privy and others

The Conduit Bundler is the core execution engine for ERC-4337 Account Abstraction on your Conduit chain. It receives UserOperations (AA transactions), validates them and submits them onchain, enabling modern wallet UX like [gas sponsorship](/chains/integrations/bundler/sponsor-gas), batched transactions, and session-based experiences.

## What Conduit provides

Conduit gives you a production-grade bundler that’s easy to enable and operate:

* A one-click installation on your Conduit chain
* A stable bundler RPC endpoint you can plug into your account abstraction stack
* A strong foundation for account abstraction infrastructure
* Support for modern ERC-4337 features including EIP-712 signing and EIP-7702

## What you still need

The bundler is only one part of the Account Abstraction stack.

To create smart accounts and generate UserOperations from your app, you will still need to integrate a wallet / smart account provider, such as:

* Privy
* ZeroDev
* or another ERC-4337-compatible smart account and paymaster stack

#### These providers handle the application-layer pieces like:

* Smart account deployment and management
* Signing flows / embedded wallets
* Session keys, recovery, etc.
* Paymaster logic (optional)

Once you integrate one of these providers, you simply configure it to use your chain and Conduit Bundler endpoint, and you’re ready to support ERC-4337 transactions.

## Compatible with the ecosystem

Conduit Bundler is designed to work out-of-the-box with popular AA stacks like Privy and ZeroDev, so you can get from “chain launched” to “smart wallets live” with minimal setup.

## Get started

# Enable Bundler on your Chain

> Learn how to install and use Conduit's Bundler. Step-by-step guide covering installation, supported RPC methods, contract addresses, and how to send UserOperations on your rollup.

## Installing the Conduit Bundler

Log in to the [Conduit app](https://app.conduit.xyz)

In your chain dashboard, go to the `Marketplace` section, and find `Conduit Bundler` in the one-click installation section.

Click `Install integration` on the right side and wait for the Conduit Bundler to complete installation.

When deploying a bundler through the **Conduit UI**, support for EntryPoint **v0.8 and v0.9** is automatically configured.\
For existing mainnet deployments, newer EntryPoint versions may be enabled on request depending on the configuration.

## General Information

### Bundler URL & Supported RPC Methods

Once deployed, your bundler URL will be available at `https://bundler-{YOUR_NETWORK_SLUG}.t.conduit.xyz/<APIKEY>`. `APIKEY` might be not present or required depending on the configuration.

Our bundler supports all `eth`-namespaced RPC methods as specified in ERC-4337 including:

* `eth_chainId`
* `eth_supportedEntryPoints`
* `eth_estimateUserOperationGas`
* `eth_sendUserOperation`
* `eth_getUserOperationByHash`
* `eth_getUserOperationReceipt`

### Contracts

#### Entrypoint

Conduit Bundler supports the following ERC-4337 EntryPoint versions:

| Version | Address                                      |
| ------- | -------------------------------------------- |
| v0.9    | `0x433709009B8330FDa32311DF1C2AFA402eD8D009` |
| v0.8    | `0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108` |
| v0.7    | `0x0000000071727De22E5E9d8BAf0edAc6f37da032` |

EntryPoint `0.6.0` is not supported.

EntryPoint **v0.9 is ABI-compatible with v0.7 and v0.8**, but introduces behavioral changes (e.g., paymaster flows and `initCode` handling).\
Note: **signing semantics changed starting in v0.8** (EIP-712 typed data).\
If your stack previously relied on v0.7 assumptions, review the migration notes below.

#### Safe Integration

The following two modules are compatible with Entrypoint `0.9.0` and are deployed with the Conduit bundler integration.

| Contract                          | Address                                      |
| --------------------------------- | -------------------------------------------- |
| Safe4337Module (version `0.3.0`)  | `0x75cf11467937ce3F2f357CE24ffc3DBF8fD5c226` |
| SafeModuleSetup (version `0.3.0`) | `0x2dd68b007B46fBe91B9A7c3EDa5A7a1063cB5b47` |

For turning your Safe wallet into a 4337-compatible smart account, see the [Safe documentation on ERC-4337](https://docs.safe.global/advanced/erc-4337/4337-safe).

#### Other Contracts

| Contract                           | Version | Address                                      |
| ---------------------------------- | ------- | -------------------------------------------- |
| SimpleAccountFactory               | v0.9    | `0xAD07bbb7bEA77E323C838481F668d22864e9F66E` |
| SimpleAccountFactory               | v0.8    | `0x13E9ed32155810FDbd067D4522C492D6f68E5944` |
| SimpleAccountFactory               | v0.7    | `0x0ACDDd4868E24aad6A16573b416133F58795A916` |
| Simple7702Account (implementation) | v0.9    | `0xa46cc63eBF4Bd77888AA327837d20b23A63a56B5` |
| Simple7702Account (implementation) | v0.8    | `0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9` |
| TestCounter                        | —       | `0x475d5a5B128c1846b86493b357e75E27201447B7` |

## EntryPoint Version Notes

If your stack previously used **EntryPoint v0.7**, newer versions introduce several improvements.

### v0.8 Improvements

* UserOperation hashing uses **EIP-712 typed data**
* Native **EIP-7702 authorizations support** is added to the Entrypoint contract
* Improved unused gas penalty behavior
* `senderCreator()` helper for factory validation

### v0.9 Improvements

* **Parallelizable paymaster signatures** via `paymasterSignature`
* **Block-range validity windows** using `validAfter` / `validUntil` (block ranges are signaled via a top-bit flag)
* Improved diagnostics via:
  * `getCurrentUserOpHash()`
  * `IgnoredInitCode`
  * `EIP7702AccountInitialized`

### Important behavioral changes

Developers migrating from older versions should be aware of the following:

* **UserOperation signing changed in v0.8** (EIP-712 typed data)
* Accounts must be created through **UserOperation `initCode`**. `SimpleAccountFactory.createAccount()` can't be used directly and can only be called by **SenderCreator**
* Paymaster signature handling changed in v0.9 (`paymasterSignature` flow); malformed `paymasterData` / signature conventions may be rejected

Even though **v0.9 maintains ABI compatibility**, bundlers and mempools must understand the updated semantics for UserOperations to be accepted.

For more details, refer to release notes below :

v0.9 - [release note](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.9.0)

v0.8 - [release note](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0)

## Sending UserOperations

Use this three-step flow to handle dynamic `preVerificationGas` (PVG) networks and reliably submit UserOperations.

Call `eth_estimateUserOperationGas` with your UserOperation. You can set `preVerificationGas` to `0x0` or omit it during estimation.

```bash
curl -s -X POST -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_estimateUserOperationGas",
    "params": [
      {
        "sender": "0x29657e08ba8c384c6e634149db8fb4e64ce29225",
        "nonce": "0x845adb2c711129d4f3966735ed98a9f09fc4ce5700000000000000000000",
        "callData": "0xe9ae5c53...",
        "callGasLimit": "0x238c",
        "verificationGasLimit": "0x462d8",
        "preVerificationGas": "0x0",
        "maxPriorityFeePerGas": "0xf4240",
        "maxFeePerGas": "0x1250f8",
        "factory": "0x2577507b78c2008ff367261cb6285d44ba5ef2e9",
        "factoryData": "0xea6d13ac...",
        "paymaster": "0xcb3871f1f320cd057a4170be2c15fee812919939",
        "paymasterVerificationGasLimit": "0x5033",
        "paymasterPostOpGasLimit": "0x0",
        "paymasterData": "0x00000000...",
        "signature": "0xc5c3ba33..."
      },
      "0x0000000071727De22E5E9d8BAf0edAc6f37da032"
    ]
  }' \
  "$RPC_URL"
```

Example response:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "preVerificationGas": "0xd8f0",
    "verificationGasLimit": "0x...",
    "callGasLimit": "0x...",
    "paymasterVerificationGasLimit": "0x..."
  }
}
```

Since PVG is dynamic on DA-enabled networks, add a 10–20% buffer to account for price changes between estimation and submission.

If the estimated PVG is `55,000` wei, a 20% buffer is `66,000` wei. Decimal
`66,000` = Hex `0x101d0`.

Resubmit the UserOperation using `eth_sendUserOperation` with the updated `preVerificationGas` (including your buffer).

```bash
curl -s -X POST -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_sendUserOperation",
    "params": [
      {
        "sender": "0x29657e08ba8c384c6e634149db8fb4e64ce29225",
        "nonce": "0x845adb2c711129d4f3966735ed98a9f09fc4ce5700000000000000000000",
        "callData": "0xe9ae5c53...",
        "callGasLimit": "0x238c",
        "verificationGasLimit": "0x462d8",
        "preVerificationGas": "0x101d0", // your updated pre verification with buffer
        "maxPriorityFeePerGas": "0xf4240",
        "maxFeePerGas": "0x1250f8",
        "factory": "0x2577507b78c2008ff367261cb6285d44ba5ef2e9",
        "factoryData": "0xea6d13ac...",
        "paymaster": "0xcb3871f1f320cd057a4170be2c15fee812919939",
        "paymasterVerificationGasLimit": "0x5033",
        "paymasterPostOpGasLimit": "0x0",
        "paymasterData": "0x00000000...",
        "signature": "0xc5c3ba33..."
      },
      "0x0000000071727De22E5E9d8BAf0edAc6f37da032"
    ]
  }' \
  "$RPC_URL"
```

If submission is delayed or conditions change, re-run estimation to refresh
PVG before sending.

## Repository

You can find the Conduit Bundler repository [here](https://github.com/conduitxyz/account-abstraction). This repository includes scripts to create a SimpleAccount, fund it, and send a test transaction.

> Learn how to install and use Conduit's Bundler. Step-by-step guide covering installation, supported RPC methods, contract addresses, and how to send UserOperations on your rollup.

# Pricing & Costs

## Bundler Plans

| **Environment** | **Monthly Price**                    |
| --------------- | ------------------------------------ |
| Testnet         | Free for the first month, then \$100 |
| Mainnet         | \$500                                |

# Sponsor Gas on your Chain

> Expand your chains Account Abstraction offerings through Conduit's marketplace

The [Conduit Bundler](/chains/integrations/bundler/) provides your chain with support for UserOperations (ERC-4337) and enables Account Abstraction features.

There are multiple ways of getting started with Account Abstraction on your chain, ZeroDev, Pimlico, Privy, and others. You can discover them all in the Conduit Marketplace.

## Install ZeroDev

ZeroDev is our preferred Account Abstraction provider and there is a One-click integration in the Conduit Marketplace making setup simple.

Log in to the [Conduit app](https://app.conduit.xyz)

In your deployment dashboard, go to the `Apps` section, and find `ZeroDev`
in the one-click installation section.

Click `Install Integration` on the right side and wait for the integration
to complete installation, if your chain uses a custom gas token you will be
required to provide a small amount to fund the deployment of ZeroDev's
contracts on your chain.

### Create a Gas Policy

After the ZeroDev integration is set up, log into the [ZeroDev app](https://dashboard.zerodev.app) and you can begin sponsoring gas for your users there.

> We've made it really easy for developers to build on top of Conduit chains by enabling access to incredibly high-performance RPCs without the need to run your own node

# RPC Nodes

Conduit Nodes provides reliable, high-performance RPC infrastructure for over 100 networks. Developers use Conduit to connect apps, rollups, and backend services to onchain data without running or maintaining their own nodes.

## Key capabilities

* **Multi-chain access** – connect to all supported mainnets and testnets with a single API key.
* **Autoscaling RPCs** – handle traffic spikes automatically without throttling or downtime.
* **Performance monitoring** – view request metrics, latency, and usage directly in the dashboard.
* **Granular access control** – restrict access by IP, domain, or wallet address.
* **Usage-based pricing** – pay only for the compute units (CUs) you use.

## Why use Conduit as a node provider

Conduit operates the chain infrastructure for many of the largest rollups in the Ethereum ecosystem. Every node runs on enterprise-grade hardware with automated recovery to maintain 99.99% uptime.

Conduit’s unified dashboard and APIs make it easy to manage keys, monitor performance, and scale RPC capacity as your application grows.

## Get started

Create and manage API keys from the Conduit app.

Send your first RPC request in a few steps using your API key.

## FAQ

**Can I use Conduit RPCs without an API key?** Yes, you can send requests to the public endpoints of chains deployed on Conduit. This is rate limited however. For the best experience, we recommend signing up on our app and creating an API key. You'll be able to use 400M CUs per month for free without a rate limit.

**Are CUs per account, org, or API key?** Compute Units are consumed at the Conduit org level. You can use your base limit (e.g. 400M CUs from the Free Plan) to access multiple networks via multiple keys under the same Conduit org.

> The same way you might use platforms like Alchemy or Infura to access Ethereum, you can use our endpoints to send requests to the built-in RPCs on Conduit chains.

# Get an API Key

The same way you might use platforms like Alchemy or Infura to access Ethereum, you can use our endpoints to send requests to the built-in RPCs on Conduit chains.

**To do this you'll need to get an API key.**

## Steps

Sign up or log in to [Conduit](https://app.conduit.xyz/).

Go to the [Nodes](https://app.conduit.xyz/nodes) page.

Append your API key to the RPC url of the rollups you wish to interact with.

Your API key will work on **all public and private endpoints** (private endpoints do not appear in the Conduit app).

***

[Get started →](https://app.conduit.xyz/nodes)

> The same way you might use platforms like Alchemy or Infura to access Ethereum, you can use our endpoints to send requests to the built-in RPCs on Conduit chains.

# Make your First RPC Request

Conduit RPC endpoints follow the [Ethereum JSON-RPC spec](https://ethereum.org/en/developers/docs/apis/json-rpc/). You send a `POST` request with a JSON body describing the method you want to call, and the node returns the result.

## Anatomy of a request

Every request body has four fields:

| Field     | Description                                                         | Example                          |
| --------- | ------------------------------------------------------------------- | -------------------------------- |
| `jsonrpc` | Protocol version — always `"2.0"`                                   | `"2.0"`                          |
| `method`  | The JSON-RPC method to call                                         | `"eth_blockNumber"`              |
| `params`  | Arguments for the method. Use `[]` if the method takes no arguments | `[]` or `["0xabc...", "latest"]` |
| `id`      | An identifier you assign, echoed back in the response               | `"1"`                            |

To call a different method, replace the `method` value with any supported JSON-RPC method and update `params` accordingly. See the examples below.

## Steps

The example below fetches the latest block number. It takes no arguments, so `params` is an empty array.

You'll need your network's RPC URL and API key from the [Conduit App](https://app.conduit.xyz/). Append them to the request URL as shown above.

```curl Request
curl -s https://[YOUR_RPC_URL]/[YOUR_API_KEY] -X POST \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":"1","method":"eth_blockNumber","params":[]}'
```

```curl Response
{"jsonrpc":"2.0","result":"0x430905","id":"1"}
```

The `result` is the block number in hex. `0x430905` = block 4,394,245.

Replace `[YOUR_RPC_URL]` and `[YOUR_API_KEY]` with your values. Supported networks and their RPC URLs can be found in the Conduit app, under the **Endpoints** tab of your API key page.

If you can't find the RPC URL you're looking for, contact the chain owner.

Run the command in your terminal. You should see a JSON response with a `result` field. If you see an error, double-check your RPC URL and API key.

## More examples

Different methods require different `params`. Here are a few common ones:

**Get the ETH balance of an address**

`params` takes an address and a block tag (`"latest"`, `"earliest"`, or a hex block number).

```curl Request
curl -s https://[YOUR_RPC_URL]/[YOUR_API_KEY] -X POST \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":"1","method":"eth_getBalance","params":["0xYOUR_ADDRESS","latest"]}'
```

```curl Response
{"jsonrpc":"2.0","result":"0x1bc16d674ec80000","id":"1"}
```

**Get the current gas price**

```curl Request
curl -s https://[YOUR_RPC_URL]/[YOUR_API_KEY] -X POST \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":"1","method":"eth_gasPrice","params":[]}'
```

```curl Response
{"jsonrpc":"2.0","result":"0x3b9aca00","id":"1"}
```

**Get the number of transactions sent from an address**

```curl Request
curl -s https://[YOUR_RPC_URL]/[YOUR_API_KEY] -X POST \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":"1","method":"eth_getTransactionCount","params":["0xYOUR_ADDRESS","latest"]}'
```

```curl Response
{"jsonrpc":"2.0","result":"0x4d","id":"1"}
```

For the full list of supported methods, refer to the [Ethereum JSON-RPC spec](https://ethereum.org/en/developers/docs/apis/json-rpc/).

# Tempo RPC Quickstart

## What is Tempo?

[Tempo](https://tempo.xyz) is a general-purpose blockchain optimized for payments. It provides a low-cost, high-throughput environment with user and developer features designed to be core to a modern payment system. Conduit is a design partner on Tempo alongside [Stripe](https://stripe.com) and [Paradigm](https://paradigm.xyz).

## What is the Tempo JSON-RPC API?

The **Tempo JSON-RPC API** is a fully managed, high-performance endpoint that you can use to read and write data on Tempo networks through standard Ethereum JSON-RPC methods. Conduit operates optimized Tempo nodes to provide a scalable, low-latency interface so you can access the network without running your own infrastructure. Your RPC URL includes an API key for authenticated access, which you can use to query chain data, send transactions, deploy contracts, and integrate Tempo into your applications with minimal setup.

### Supported Networks

| Network                  | Type    | Chain ID | HTTP | WSS |
| ------------------------ | ------- | -------- | ---- | --- |
| Tempo Mainnet            | Mainnet | 4217     | Yes  | Yes |
| Tempo Testnet (Moderato) | Testnet | 42431    | Yes  | Yes |

## Getting a Tempo Endpoint

<video src="https://files.buildwithfern.com/visual-editor-images/docs.conduit-stg.xyz/2025-12-09T12:42:32.543Z/rpc-nodes/getting-started/tempo-rpc-quickstart/getting-tempo-rpc.mp4" title="getting-tempo-rpc" controls />

### Step by Step Guide

Go to [app.conduit.xyz](https://app.conduit.xyz) and sign in with your work email.

Navigate to [app.conduit.xyz/nodes](https://app.conduit.xyz/nodes) where you
will be able to create an API key and access supported endpoints.

Click `Create API key` to access your endpoints.

From the `Endpoints` tab, search for the Tempo Mainnet or Tempo Testnet endpoint and copy the
RPC URL with your newly created API key appended to it.

## More Information

Learn more about Conduit RPC Nodes.

Get in-depth information about Tempo.

# Agent Skills

Give your AI coding agent full knowledge of every Conduit RPC API with a single command. Once installed, your agent knows every endpoint, network, authentication flow, and payment pattern without any manual prompting.

Skills work with [Claude Code](https://www.anthropic.com/claude-code), [Codex](https://openai.com/index/codex/), [Cursor](https://cursor.com), [VS Code Copilot](https://code.visualstudio.com/docs/copilot/overview), and any AI tool that supports the [Agent Skills specification](https://agentskills.io).

## Install the skill

```bash
npx skills add conduitxyz/skills --yes
```

This installs the `conduit-rpc-gateway` skill, which teaches your agent how to make paid JSON-RPC calls to 60+ networks on [Conduit Nodes](https://hub.conduit.xyz/) using [MPP](https://mpp.dev/overview) payment channels via [Tempo](https://tempo.xyz).

| Skill                 | Auth method                 | Best for                                                             |
| --------------------- | --------------------------- | -------------------------------------------------------------------- |
| `conduit-rpc-gateway` | MPP session (USDC on Tempo) | Agents that need RPC access to any Conduit rollup without an API key |

After installation, your agent will walk you through wallet setup and handle authentication automatically.

## What's included

The skill covers the full Conduit RPC gateway surface:

* **EVM JSON-RPC:** Standard methods (`eth_blockNumber`, `eth_getBalance`, `eth_call`, `eth_getLogs`, `eth_sendRawTransaction`, and more) across all Conduit networks
* **60+ Networks:** All networks listed on the [Conduit Hub](https://hub.conduit.xyz) or configured as discoverable are automatically supported. This includes 60+ networks such as Tempo, Plume, and Polygon Katana.
* **Payment flow:** Automatic MPP session management -- payment channels, signed vouchers, and settlement
* **Discovery:** Programmatic network discovery via `GET /openapi.json` and `GET /llms.txt`
* **Error handling:** Guidance for `402 Payment Required`, `404 Not Found`, and JSON-RPC error responses

The skill includes endpoint URLs, authentication patterns, code examples, CLI workflows, and network routing conventions.

## How it works

The `conduit-rpc-gateway` skill uses pay-as-you-go payment channels instead of API keys. Your agent authenticates by opening a USDC payment channel on Tempo, then sends signed off-chain vouchers with each request -- no gas fees after the first transaction.

**Cost:** \$0.00005 per JSON-RPC call (\~20,000 requests per 1 USDC).

**Gateway URL:** `https://mpp.conduit.xyz`

**Route format:** `POST https://mpp.conduit.xyz/:network-id`

### Payment flow

1. Your agent sends a JSON-RPC request to `/:network-id`
2. The server returns `402 Payment Required` with a `WWW-Authenticate: Payment` header
3. The client opens a payment channel on-chain (first request only)
4. Subsequent requests include a signed voucher -- no gas, no block confirmation, instant
5. Call `session.close()` to settle on-chain; unused deposit is refunded

### Choose a client

Your agent will prompt you to choose a client before making any RPC requests:

1. **Tempo Wallet** (Recommended) -- Managed MPP client with built-in spend controls. No manual key management.
2. **mppx** -- Lightweight MPP client via `npx`. Manages keys internally.

### Set up and fund your wallet

**Tempo Wallet:**

```bash
curl -fsSL https://tempo.xyz/install | bash
tempo wallet login
```

**mppx:**

```bash
npx mppx account create
```

Your wallet needs USDC on Tempo. At \$0.00005 per request, 1 USDC covers approximately 20,000 RPC calls.

**With Tempo Wallet:**

```bash
tempo request -X POST https://mpp.conduit.xyz/zora-mainnet-0 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
```

**With mppx:**

```bash
npx mppx -X POST https://mpp.conduit.xyz/zora-mainnet-0 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
```

## Supported methods

| Method                                    | Description                                      |
| ----------------------------------------- | ------------------------------------------------ |
| `debug_getBadBlocks`                      | Get a list of bad blocks seen on the network     |
| `debug_getRawBlock`                       | Get the RLP-encoded block                        |
| `debug_getRawHeader`                      | Get the RLP-encoded block header                 |
| `debug_getRawReceipts`                    | Get the RLP-encoded transaction receipts         |
| `debug_getRawTransaction`                 | Get the RLP-encoded transaction                  |
| `debug_traceCall`                         | Trace a call without creating a transaction      |
| `eth_accounts`                            | Get a list of addresses owned by the client      |
| `eth_blobBaseFee`                         | Get the base fee per blob gas in wei             |
| `eth_blockNumber`                         | Get the latest block number                      |
| `eth_call`                                | Execute a read-only contract call                |
| `eth_chainId`                             | Get the chain ID                                 |
| `eth_coinbase`                            | Get the client coinbase address                  |
| `eth_createAccessList`                    | Create an access list for a transaction          |
| `eth_estimateGas`                         | Estimate gas for a transaction                   |
| `eth_feeHistory`                          | Get fee history for a block range                |
| `eth_gasPrice`                            | Get the current gas price                        |
| `eth_getAccount`                          | Get account information for an address           |
| `eth_getBalance`                          | Get an address's native token balance            |
| `eth_getBlockByHash`                      | Get block data by block hash                     |
| `eth_getBlockByNumber`                    | Get block data by block number                   |
| `eth_getBlockReceipts`                    | Get all transaction receipts for a block         |
| `eth_getBlockTransactionCountByHash`      | Get transaction count in a block by hash         |
| `eth_getBlockTransactionCountByNumber`    | Get transaction count in a block by number       |
| `eth_getCode`                             | Get contract bytecode                            |
| `eth_getFilterChanges`                    | Poll a filter for new results                    |
| `eth_getFilterLogs`                       | Get all logs matching a filter ID                |
| `eth_getLogs`                             | Get event logs matching a filter                 |
| `eth_getProof`                            | Get account and storage Merkle proofs            |
| `eth_getRawTransactionByHash`             | Get raw transaction data by hash                 |
| `eth_getStorageAt`                        | Get a value from contract storage                |
| `eth_getTransactionByBlockHashAndIndex`   | Get a transaction by block hash and index        |
| `eth_getTransactionByBlockNumberAndIndex` | Get a transaction by block number and index      |
| `eth_getTransactionByHash`                | Get a transaction by hash                        |
| `eth_getTransactionCount`                 | Get an address's nonce                           |
| `eth_getTransactionReceipt`               | Get a transaction receipt                        |
| `eth_getUncleByBlockNumberAndIndex`       | Get an uncle block by number and index           |
| `eth_getUncleCountByBlockHash`            | Get uncle count in a block by hash               |
| `eth_getUncleCountByBlockNumber`          | Get uncle count in a block by number             |
| `eth_maxPriorityFeePerGas`                | Get the current max priority fee per gas         |
| `eth_newBlockFilter`                      | Create a filter for new blocks                   |
| `eth_newFilter`                           | Create a log filter                              |
| `eth_newPendingTransactionFilter`         | Create a filter for pending transactions         |
| `eth_protocolVersion`                     | Get the Ethereum protocol version                |
| `eth_sendRawTransaction`                  | Submit a signed transaction                      |
| `eth_sendRawTransactionConditional`       | Submit a signed transaction with conditions      |
| `eth_sendTransaction`                     | Submit a transaction                             |
| `eth_sign`                                | Sign data with an address                        |
| `eth_signTransaction`                     | Sign a transaction without submitting            |
| `eth_simulateV1`                          | Simulate transactions against virtual blocks     |
| `eth_subscribe`                           | Subscribe to real-time events                    |
| `eth_syncing`                             | Get sync status                                  |
| `eth_uninstallFilter`                     | Remove a filter                                  |
| `eth_unsubscribe`                         | Cancel a subscription                            |
| `net_listening`                           | Check if the client is listening for connections |
| `net_version`                             | Get the network ID                               |
| `web3_clientVersion`                      | Get the client version                           |
| `web3_sha3`                               | Compute a Keccak-256 hash                        |
| `alchemy_getTransactionReceipts`          | Get transaction receipts for a given block       |

## Example networks

| Network        | Route              |
| -------------- | ------------------ |
| Tempo          | `/tempo`           |
| Plume          | `/plume-mainnet-1` |
| Polygon Katana | `/katana`          |

Discover all available networks programmatically via [`/openapi.json`](https://mpp.conduit.xyz/openapi.json) or [`/llms.txt`](https://mpp.conduit.xyz/llms.txt).

## Programmatic usage

You can also use the `mppx/client` SDK to make paid RPC calls from your application:

```typescript
import { tempo } from 'mppx/client'
import { createClient, http } from 'viem'
import { privateKeyToAccount } from 'viem/accounts'
import { tempo as tempoChain } from 'viem/chains'

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
const client = createClient({ account, chain: tempoChain, transport: http() })
const session = tempo.session({ client, maxDeposit: '1' })

const response = await session.fetch(
  'https://mpp.conduit.xyz/zora-mainnet-0',
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      method: 'eth_blockNumber',
      params: [],
      id: 1,
    }),
  }
)

const data = await response.json()
console.log(data)

// Close the session to settle on-chain; unused deposit is refunded
await session.close()
```

Never hardcode private keys. Always read them from environment variables or a secure store.

A single payment session can make calls across different networks -- the channel is opened once, and subsequent requests to any network use the same signed vouchers.

## How skills work

Agent Skills follow an [open specification](https://agentskills.io/specification). A skill is a set of Markdown files that contain structured knowledge -- API docs, code examples, decision trees, and rules -- that an AI agent reads and follows.

When you run `npx skills add`, the skill files are added to your project. Your AI agent reads these files and uses them as context when writing code or making API requests.

|                    | Agent Skills                                      | MCP Server                                              |
| ------------------ | ------------------------------------------------- | ------------------------------------------------------- |
| **What it does**   | Teaches the agent *how* to use APIs               | Gives the agent *tools* to call APIs directly           |
| **When it's used** | When the agent writes code that uses Conduit APIs | When the agent needs to query live blockchain data      |
| **Output**         | The agent writes code using Conduit APIs          | The agent gets blockchain data back in the conversation |

## Next steps

View the skill source and contribute.

Browse all supported networks.

Learn about the Machine Payments Protocol.

Read the open Agent Skills specification.

# Throughput

## What is throughput?

"Throughput" is the volume of requests your application can successfully send to Conduit RPC gateways within a period of time. Limits are enforced in Compute Units per second (CU/s), [learn more](/rpc-nodes/information/compute-units).

## Current limits

| Tier            | Throughput   |
| --------------- | ------------ |
| Unauthenticated | 200 CU/s     |
| Free Plan       | 12,500 CU/s  |
| Pro Plan        | 250,000 CU/s |

Additional limits:

| Limit                  | Value |
| ---------------------- | ----- |
| Max request time       | 35 s  |
| Max batch request size | 5 MB  |

## Method-specific limits

When using the indexed logs backend:

* `eth_getLogs`: up to 10,000 log events per request
* `eth_getLogs` block range: up to 2,000 blocks per request

Tips for `eth_getLogs`:

* Page by block range (for example, chunks of ≤2,000 blocks) and by topics to keep event counts below limits
* Prefer stable block tags (for example, a specific block number) when possible
* Requesting more than 10,000 logs fails with HTTP 400 (error code -32005). Example response:
  ```json
  {
    "jsonrpc": "2.0",
    "error": {
      "code": -32005,
      "message": "logs count limit exceeded (10000) consider refine/narrow down your query"
    },
    "id": 0
  }
  ```

## Handling 429 (rate limited)

If you receive HTTP 429:

* Back off and retry with exponential backoff and jitter; honor `Retry-After` if present
* Reduce concurrency; queue or rate limit at the client
* Use batch requests to reduce overhead (stay under 5 MB)
* Prefer WebSocket subscriptions for high-frequency event use cases
* For large log scans, paginate ranges rather than one wide query

## Best practices

* Understand method cost: some methods are heavier than others. See [Compute Units](/rpc-nodes/information/compute-units)
* Batch sensibly: group similar calls into a single batch where appropriate
* Cache read results and pin to specific block numbers when possible to avoid repeated work
* Use separate API keys per environment and service to isolate traffic. See [Get an API key](/rpc-nodes/getting-started/get-api-key) and [Access Control & Settings](/rpc-nodes/guides/access-controls-settings)

## Increasing limits

Upgrade your plan or contact Conduit for higher limits:

* See [Pricing & Costs](/rpc-nodes/information/pricing-costs)
* Pro and Enterprise plans support significantly higher sustained throughput

# WebSockets

## Quick start: connect to Conduit WebSockets

Open a connection using the WSS URL from your Nodes dashboard. The URL is shown next to each API key and may include a path segment. Use that exact value.

Example using wscat:

```bash
wscat -c wss://rpc-[YOUR_NETWORK_SLUG].t.conduit.xyz/<API_KEY>
```

To create or manage keys, see [Get an API key](/rpc-nodes/getting-started/get-api-key).

## What are WebSockets?

WebSockets is a bidirectional protocol that keeps a persistent connection between a client and a server. Unlike HTTP, clients don’t need to poll for updates. With an open WebSocket connection, the server can push network updates to subscribed clients (for example, when new blocks are produced or matching logs are found).

## When to use HTTP instead of WebSockets

Use HTTPS for standard JSON-RPC requests (`eth_call`, `eth_getBlockByNumber`, `eth_sendRawTransaction`). Reserve WebSockets for push-style subscriptions.

##### Why HTTP is often better for requests:

1. Reliability and error signals: HTTP provides status codes and mature retry tooling; WebSockets can fail silently without careful client handling
2. Load balancing: Each HTTP request is routed to the healthiest backend; a long-lived WebSocket stays on one node
3. Retries and backoff: HTTP clients commonly support automatic retries and backoff; WebSocket JSON-RPC requires custom id tracking and reconnect logic
4. Compression: HTTP compression can reduce bandwidth for large payloads

## Subscriptions: real-time updates

After connecting, use standard Ethereum JSON-RPC methods to manage subscriptions:

* `eth_subscribe`
* `eth_unsubscribe`

Examples

Subscribe to new heads:

```json
{ "jsonrpc": "2.0", "id": 1, "method": "eth_subscribe", "params": ["newHeads"] }
```

Subscribe to logs for an address and topic:

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "eth_subscribe",
  "params": [
    "logs",
    {
      "address": "0x0000000000000000000000000000000000000000",
      "topics": [
        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
      ]
    }
  ]
}
```

Unsubscribe:

```json
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "eth_unsubscribe",
  "params": ["<SUBSCRIPTION_ID>"]
}
```

## Connection management

* Use exponential backoff with jitter when reconnecting and resubscribing
* Send application-level heartbeats if your client or environment doesn’t automatically respond to ping/pong
* Deduplicate messages by block number or transaction hash when reconnecting
* Limit the number of concurrent subscriptions per connection; scope filters narrowly

## Limits and throughput

* WebSocket traffic counts toward your organization’s throughput. See [Throughput](/rpc-nodes/information/throughput)
* Avoid very large subscription result sets; filter by `address` and `topics`
* If the connection is idle for an extended period, servers may close it. Reconnect with backoff

## Best practices checklist

* Keep one WebSocket per service; avoid opening many connections
* Scope subscriptions narrowly (filter by `address` and `topics`)
* Reconnect with exponential backoff and jitter; resubscribe on reconnect
* Implement heartbeats or respond to ping/pong
* Fall back to HTTP for historical scans and catch-up reads

# Compute Units

> We use Compute Units (CUs) to measure how many computational resources (CPU, RAM, disk, etc.) an API method uses

We use Compute Units (CUs) to measure how many computational resources (CPU, RAM, disk, etc.) an API method uses. This allows us to provide fair and transparent pricing (e.g. no over spending for simple requests).

| Method                                   | Cost |
| ---------------------------------------- | ---- |
| debug\_traceTransaction                  | 300  |
| debug\_traceCall                         | 300  |
| debug\_traceBlockByHash                  | 300  |
| debug\_traceBlockByNumber                | 300  |
| trace\_get                               | 75   |
| trace\_block                             | 75   |
| trace\_transaction                       | 75   |
| trace\_call                              | 75   |
| trace\_rawTransaction                    | 75   |
| trace\_filter                            | 75   |
| trace\_replayTransaction                 | 3000 |
| trace\_replayBlockTransactions           | 3000 |
| net\_version                             | 0    |
| eth\_chainId                             | 0    |
| eth\_syncing                             | 0    |
| eth\_protocolVersion                     | 0    |
| net\_listening                           | 0    |
| eth\_uninstallFilter                     | 10   |
| eth\_accounts                            | 10   |
| eth\_blockNumber                         | 10   |
| eth\_subscribe                           | 10   |
| eth\_unsubscribe                         | 10   |
| eth\_feeHistory                          | 10   |
| eth\_maxPriorityFeePerGas                | 10   |
| eth\_createAccessList                    | 10   |
| eth\_getTransactionReceipt               | 15   |
| eth\_getUncleByBlockHashAndIndex         | 15   |
| eth\_getUncleByBlockNumberAndIndex       | 15   |
| eth\_getTransactionByBlockHashAndIndex   | 15   |
| eth\_getTransactionByBlockNumberAndIndex | 15   |
| eth\_getUncleCountByBlockHash            | 15   |
| eth\_getUncleCountByBlockNumber          | 15   |
| web3\_clientVersion                      | 15   |
| web3\_sha3                               | 15   |
| eth\_getBlockByNumber                    | 15   |
| eth\_getStorageAt                        | 15   |
| eth\_getTransactionByHash                | 15   |
| eth\_gasPrice                            | 20   |
| eth\_getBalance                          | 20   |
| eth\_getCode                             | 20   |
| eth\_getFilterChanges                    | 20   |
| eth\_newBlockFilter                      | 20   |
| eth\_newFilter                           | 20   |
| eth\_getBlockTransactionCountByHash      | 20   |
| eth\_getBlockTransactionCountByNumber    | 20   |
| eth\_getProof                            | 20   |
| eth\_getBlockByHash                      | 20   |
| eth\_getTransactionCount                 | 20   |
| eth\_call                                | 75   |
| eth\_getFilterLogs                       | 75   |
| eth\_getLogs                             | 75   |
| eth\_estimateGas                         | 75   |
| eth\_sendRawTransaction                  | 200  |
| eth\_sendRawTransactionSync              | 200  |
| eth\_getBlockReceipts                    | 200  |

Other methods generally priced at 25 CUs.

# Pricing & Costs

> All Conduit organisations are on the _Free Plan_ by default. You can upgrade to our _Pro Plan_ in a few clicks or contact sales for our Enterprise Plan.

All Conduit organisations are on the *Free Plan* by default. You can upgrade to our *Pro Plan* in a few clicks or contact sales for our Enterprise Plan.

Rollup customers who have deployed a mainnet get the *Conduit Nodes Pro Plan*
for free.

## Plans

| Plan           | Included CUs | API Keys  | Support          | Price      | Autoscaling       |
| -------------- | ------------ | --------- | ---------------- | ---------- | ----------------- |
| **Free**       | 400M         | 1         | —                | \$0/month  | –                 |
| **Pro**        | 1B           | 10        | Standard support | \$50/month | \$0.10 per 1M CUs |
| **Enterprise** | Custom       | Unlimited | Priority support | Custom     | Custom            |

*A Compute Unit (CU) measures how many computational resources (CPU, RAM, disk, etc.) an API method uses. See [Compute Units](/rpc-nodes/information/compute-units) for details.*

If you're interested in an Enterprise plan, please [contact sales](mailto:sales@conduit.xyz).

## Autoscaling

Paid plans autoscale at \$0.10/1M CUs once the base CU limit has been reached. e.g. On the Pro Plan, once your organization has consumed the 1B CU base limit included in your plan within a given month, every additional 1M CUs will cost \$0.10. You can add a spend limit in settings, which allows you to control the maximum amount that can be spent each month.

> Learn how to configure your API key settings to manage access with domain, IP, and address restrictions. Discover how to regenerate or delete your API key as needed to maintain security and control over your application.

# Access Control & Settings

Manage your API key access by configuring permissions across different security dimensions. To manage these settings, go to **Nodes Dashboard** → select the **API key** you want to configure → click **Access controls** tab at the top.

## Access Control Lists (ACLs)

### Restrict Access to Networks

Limit your API key to only specified networks. By default, an API key works with all public and private networks on Conduit. To restrict access for your key to select networks, configure them individually.

![Access Network](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/d37a882f949eea0eeb20f08a2193e2c8ae52dc7be61fefcc2500cf757fd12adb/docs/pages/nodes/images/acl-network.png)

Click **Configure networks** to open a sidebar to toggle each network on or off.

**Note:** By default API keys can access [hidden
networks](/faq#whats-the-difference-between-a-discoverable-and-hidden-chain),
if you wish to block all hidden networks and restrict to only specified
networks, click the toggle **Allow access to hidden chains** in the sidebar

![Access Network Sidebar](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/9a2100d0b970c3d196025cf622f4d1b430d3525a4c11a04834c3821e494a89d6/docs/pages/nodes/images/acl-network-sidebar-updated.png)

### Restrict Access to Addresses

Limit read requests to specific addresses. This will only affect the following methods: `eth_call`, `eth_getBalance`, `eth_getTransactionCount`, `eth_getCode`, `eth_getStorageAt`, `eth_getLogs`, `eth_newFilter`, `eth_subscribe`. Other read methods can still be called on addresses that are not whitelisted.

![Access Address](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/d15b8e99e8393055769ceba95d30af469b2107809c82e7f1cff42b8ed8ea8845/docs/pages/nodes/images/acl-address.png)

### Restrict Access to Domains

Allow read and write requests only from specified domains. Wildcard domains are also supported; e.g. \*.zora.co

![Access Domain](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/c0b8fc2358e24ec5228394a01c4ab812e1b3e04c95ce70a3eb1f89033f0e3827/docs/pages/nodes/images/acl-domain.png)

### Restrict Access to IPs

Limit access to your keys by allowing read and write requests only from specific IPv4 addresses. CIDR notation is also supported; e.g. 10.10.0.0/16.

![Access IP](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/5a6ea489b9756d239d96e0f9606e080174addbb70c70a239758c9d822079d2a4/docs/pages/nodes/images/acl-ip.png)

### Restrict Access to JSON-RPC Methods

Control which JSON-RPC methods can be accessed through your API key. This allows you to limit the functionality available to your applications by specifying only the methods they need.

![Access JsonRpc](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/00fa40278aaf1dd80704a6ecda4f8cdf838fc75597844cf26926254b3576ee0d/docs/pages/nodes/images/acl-method.png)

## Key Management

### Regenerate a Key

Generates a new key string while preserving existing settings and network configurations. Previous key becomes invalid once regenerated.

![Key Delete](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/0c741739b07706a29c8e88d351651d421efed39ff6606d18848d664b0dc60623/docs/pages/nodes/images/nodes-regenerate-key.png)

### Delete a Key

**Permanently** removes the API key and prevents all future client access.

![Key Delete](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/922a3791f16fd9002b70a9ac67ea3a6af07f3326d3005efa34a0a6cea539aea5/docs/pages/nodes/images/nodes-delete-key.png)

## FAQ

### What is the default behavior for traffic?

By default, if no restrictions are specified, all traffic is allowed. This means that any incoming traffic will be accepted unless you configure specific rules.

### How does access work after adding restrictions?

Once you specify any restrictions, the system switches to a "deny-all-except-allowed" model. This means that all traffic is blocked by default, and only the traffic explicitly allowed in your Access Control Lists (ACLs) will be permitted.

### Do restrictions in one Access Control category affect others?

No, each Access Control category (such as domains, addresses, etc.) operates independently. For example, if you specify restrictions for IP addresses but leave domain restrictions unspecified, all domains will remain accessible, while only the specified IP addresses will be allowed access.

### How are Access Control Lists applied?

ACLs are applied per API key. If no restrictions are set for a specific category (e.g., domains or addresses), the default behavior allows all traffic in that category.

### When do changes to Access Control settings take effect?

Once you save your changes, there is a delay of approximately 5 minutes before the new settings are applied. Please ensure that you save your changes for them to take effect.

> Create a Checkly API check to monitor any JSON-RPC endpoint.

# RPC Monitoring with Checkly

Follow this guide to set up additional external uptime monitoring and alerting using Checkly for your JSON-RPC endpoints.

## Create an API Check

From the Checkly dashboard, click "Create Check" and select "API check".

![Create Check → API check](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/7c2f2143fc5cb9c172215f0d83e6d48a7d73b7f810d8d44b8f7c5cbb14ac871f/docs/pages/guides/imgs/create-from-scratch.png)

```json
{
  "method": "POST",
  "url": "https://<your-json-rpc-endpoint",
  "bodyType": "JSON"
}
```

![Configure API check](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/e23899316b59cfbd61dc166d3fd8606fc881f61f5901e498b960dce0fddc9559/docs/pages/guides/imgs/create-an-api-check.png)

Use the standard `eth_syncing` request to verify the node is up-to-date and responsive.

```json
{
  "jsonrpc": "2.0",
  "method": "eth_syncing",
  "params": [],
  "id": 1
}
```

![JSON body in editor](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/9ea1f7c50f2dab11fd3946d50a6c406150a9bc94441ca76f5f58601aac8c11d8/docs/pages/guides/imgs/json-shell.png)

In Assertions and Limits, add two assertions against the JSON body targeting `$.result` to confirm the node reports a non-syncing state and can serve JSON-RPC traffic.

![Assertions configuration](https://files.buildwithfern.com/conduit.docs.buildwithfern.com/7136d0de2fddbd382f446d06fcede07c01fa708b378214b39df0993ce44b90ee/docs/pages/guides/imgs/assertions.png)

Adjust as needed for your use case.

We typically use: all regions, 5-minute intervals, and max retry of 1.

```
```

> Best practices for reliable nonce management on Arbitrum Nitro, with minimal viem examples and guidance to avoid optimistic nonce mismatches.

# Managing Nonces

This guide outlines strategies to manage transaction nonces safely on Arbitrum (Nitro), with a focus on ordering, concurrency, and recovery. It includes minimal `viem` examples and applies to both frontend and backend systems.

## What is a nonce?

* In EVM-compatible blockchains, a nonce is the count of transactions sent from an address.
* Each new transaction must use a unique, sequential nonce:
  * The first transaction uses nonce 0.
  * The next uses nonce 1, and so on.
* If a transaction uses a nonce that’s already been used or skipped, the blockchain will reject it.

## Common challenges

* Race conditions: Sending multiple transactions simultaneously may reuse the same nonce.
* RPC delays: Fetching nonces from a slow RPC endpoint may lead to stale values.
* Page reloads: If the app restarts, in-memory nonce tracking resets.

To avoid these, implement a clear source of truth, local tracking, and safe concurrency controls.

## Strategy

We’ll use a two-layer nonce management system:

* Remote layer: Fetches the latest confirmed nonce from the blockchain via RPC.
* Local layer: Tracks and increments nonces in localStorage or in-memory state for pending transactions.

Flow:

```text
Blockchain (RPC)
  ↓
Fetch latest confirmed nonce
  ↓
Store locally (nonce cache)
  ↓
Increment locally for each new tx
  ↓
Submit tx → update nonce tracker
```

## Best practices

### Arbitrum (Nitro) specifics

* Nonce mismatches on Arbitrum commonly happen when the client optimistically bumps the nonce before the prior transaction is confirmed as included.
* When a transaction is submitted with a nonce that is too high on Nitro, the node will hold it briefly (about 1 second by default) to see if intermediate transactions arrive to fill the gap. If they don’t, you’ll receive a "nonce too high" error afterwards.
* That 1-second hold can delay feedback and encourage clients to keep submitting higher nonces. Until client-side logic is improved, reduce this "gap-hold" time from \~1s to \~0 to get immediate feedback. This allows you to quickly detect incorrect nonces before sending further transactions with even higher nonces.
* Practical approach:
  * Gate sending of nonce N+1 on evidence that N is included (or at least that N is accepted and visible in `pending`).
  * If you receive "nonce too high", immediately re-sync from RPC and pause higher-nonce submissions until the gap is resolved.
  * Ask your node/provider to minimize the hold window so errors surface immediately (Conduit can configure this on managed stacks).

#### Example (TypeScript script): Gated nonces on Arbitrum Nitro

```ts copy
import {
  createPublicClient,
  createWalletClient,
  http,
  parseEther,
  type Address,
} from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { arbitrum } from "viem/chains";

// 1) Configure clients for Arbitrum Nitro (Node.js script)
const RPC_URL = process.env.RPC_URL || "https://arb1.arbitrum.io/rpc";
const PRIVATE_KEY = process.env.PRIVATE_KEY as `0x${string}`;
if (!PRIVATE_KEY) {
  throw new Error("Missing PRIVATE_KEY env var (hex string, 0x-prefixed).");
}
const account = privateKeyToAccount(PRIVATE_KEY);

const publicClient = createPublicClient({
  chain: arbitrum,
  transport: http(RPC_URL),
});
const walletClient = createWalletClient({
  account,
  chain: arbitrum,
  transport: http(RPC_URL),
});
const address = account.address;

// 2) Helpers
async function getPendingNonce(addr: Address) {
  return publicClient.getTransactionCount({
    address: addr,
    blockTag: "pending",
  });
}

async function waitUntilPendingNonceAtLeast(
  addr: Address,
  target: number,
  pollMs = 300,
  timeoutMs = 6000,
) {
  const start = Date.now();
  while (Date.now() - start < timeoutMs) {
    const pending = await getPendingNonce(addr);
    if (pending >= target) return true;
    await new Promise((r) => setTimeout(r, pollMs));
  }
  return false;
}

// 3) Gated send: explicit nonce, then wait for pending to advance
export async function sendWithGatedNonce(to: Address, valueEth = "0.01") {
  let next = await getPendingNonce(address);
  try {
    const hash = await walletClient.sendTransaction({
      to,
      value: parseEther(valueEth),
      nonce: next,
    });
    // Wait for mempool to reflect acceptance before attempting N+1
    await waitUntilPendingNonceAtLeast(address, next + 1);
    return hash;
  } catch (err: any) {
    const msg = String(err?.message || "").toLowerCase();
    if (msg.includes("nonce too high")) {
      const resynced = await getPendingNonce(address);
      throw new Error(`Nonce too high. Resynced pending nonce=${resynced}`);
    }
    if (msg.includes("nonce too low")) {
      const resynced = await getPendingNonce(address);
      throw new Error(`Nonce too low. Resynced pending nonce=${resynced}`);
    }
    throw err;
  }
}

// 4) Example usage
// RPC_URL="https://arb1.arbitrum.io/rpc" PRIVATE_KEY="0x..." node script.ts
// await sendWithGatedNonce("0xRecipientAddressHere" as Address, "0.01");
```

### Source of truth: latest vs pending

* Use `latest` to align with confirmed state (stable, conservative).
* Use `pending` to include mempool (higher throughput, risk of drift).
* For parallel send flows, prefer `pending` plus a local tracker to avoid reuse.

### Fetching the nonce (viem)

```ts copy
// Latest confirmed nonce
const latest = await client.getTransactionCount({
  address,
  blockTag: "latest",
});

// Include mempool transactions
const pending = await client.getTransactionCount({
  address,
  blockTag: "pending",
});
```

### Local tracking and persistence

Maintain a next-nonce per address locally

Recommended algorithm (per address):

1. On startup, read `pending` nonce from RPC as the baseline.
2. Compare with any locally cached value and keep the max.
3. On each send:
   * Read current local next-nonce.
   * Reserve it (optimistically).
   * Submit tx with that nonce.
   * Increment and persist the next-nonce.
4. On error indicating nonce drift, re-sync from RPC and update local store.

Minimal usage pattern:

```ts
const next = await takeNextNonce(address); // reserves and returns next nonce
await walletClient.sendTransaction({ ...tx, nonce: next });
```

### Concurrency control (avoid races)

* Use a per-address mutex/lock (backend) or single-flight queue (frontend).
* Only one "allocate nonce and send" critical section should run at a time.

```ts
await withAddressLock(address, async () => {
  const next = await takeNextNonce(address);
  const hash = await walletClient.sendTransaction({ ...tx, nonce: next });
  return hash;
});
```

### Handling errors and re-sync

* "nonce too low": Your local tracker is behind; re-fetch `pending`, set local to max, retry.
* "replacement transaction underpriced": If intentionally replacing, bump fees sufficiently; otherwise choose a new higher nonce.
* Dropped transactions: If a tx is dropped, you may reuse its nonce after confirming it’s not in mempool; safer is to send a replacement with higher fee.
* Periodically re-sync from RPC (timer or after N sends).

### Replacement transactions (EIP-1559)

* To replace a pending tx, send a new tx with the same nonce and a higher effective priority fee/tip.
* Ensure the replacement increases fees enough to be accepted by the node/p2p policy.

### When to rely on node-managed nonces

* It’s fine to omit `nonce` and let the node set it if:
  * You send strictly sequential transactions (no parallelism).
  * Throughput and latency requirements are modest.
* If you need parallelism or precise control, manage nonces locally.

## Client implementation (React + viem)

### Install

```bash copy
npm install viem
```

### Hook: `useNonceManager`

```ts copy
import { useCallback, useEffect, useRef, useState } from "react";
import type { Address, PublicClient } from "viem";

const NONCE_STORAGE_KEY = "nonce-tracker";

export function useNonceManager(client: PublicClient, address?: Address) {
  const [nonce, setNonce] = useState<number | null>(null);
  const isFetching = useRef(false);

  const fetchOnChainNonce = useCallback(async () => {
    if (!address || isFetching.current) return;
    isFetching.current = true;
    try {
      const latest = await client.getTransactionCount({
        address,
        blockTag: "latest",
      });
      setNonce(latest);
      localStorage.setItem(`${NONCE_STORAGE_KEY}:${address}`, String(latest));
    } finally {
      isFetching.current = false;
    }
  }, [client, address]);

  const loadLocalNonce = useCallback(() => {
    if (!address) return;
    const saved = localStorage.getItem(`${NONCE_STORAGE_KEY}:${address}`);
    if (saved) setNonce(Number(saved));
  }, [address]);

  const getNextNonce = useCallback(() => {
    if (nonce === null) throw new Error("Nonce not initialized");
    const next = nonce;
    const newNonce = nonce + 1;
    setNonce(newNonce);
    if (address) {
      localStorage.setItem(`${NONCE_STORAGE_KEY}:${address}`, String(newNonce));
    }
    return next;
  }, [nonce, address]);

  const resetNonce = useCallback(() => {
    setNonce(null);
    if (address) localStorage.removeItem(`${NONCE_STORAGE_KEY}:${address}`);
  }, [address]);

  useEffect(() => {
    loadLocalNonce();
    fetchOnChainNonce();
  }, [loadLocalNonce, fetchOnChainNonce]);

  return { nonce, getNextNonce, fetchOnChainNonce, resetNonce };
}
```

### Component: submit a transaction on Arbitrum

```tsx copy
import React from "react";
import {
  createPublicClient,
  createWalletClient,
  custom,
  http,
  parseEther,
  type Address,
} from "viem";
import { arbitrum } from "viem/chains";
import { useNonceManager } from "./hooks/useNonceManager";

export function TransactionSender() {
  const publicClient = createPublicClient({
    chain: arbitrum,
    transport: http("https://arb1.arbitrum.io/rpc"),
  });
  const walletClient = createWalletClient({
    chain: arbitrum,
    // In a browser, prefer the injected provider (e.g., MetaMask)
    transport:
      typeof window !== "undefined" && (window as any).ethereum
        ? custom((window as any).ethereum)
        : http("https://arb1.arbitrum.io/rpc"),
  });

  const address = "0xYourAddressHere" as Address;
  const { nonce, getNextNonce, fetchOnChainNonce } = useNonceManager(
    publicClient,
    address,
  );

  const sendTransaction = async () => {
    // Avoid optimistic bumps: only allocate the next nonce when sending
    const currentNonce = getNextNonce();

    const tx = {
      to: "0xRecipientAddress" as Address,
      value: parseEther("0.01"),
      nonce: currentNonce,
      gas: 21000n,
    };

    const hash = await walletClient.sendTransaction(tx);
    console.log("Tx sent:", hash);

    // Optionally re-sync after submission
    fetchOnChainNonce();
  };

  return (
    <div className="p-4">
      <p>Current Nonce: {nonce ?? "Loading..."}</p>
      <button onClick={sendTransaction}>Send Transaction</button>
    </div>
  );
}
```

Arbitrum tip: gate sending of nonce N+1 until N is visible in `pending` (or confirmed), and avoid incrementing local state until you actually send. If you receive "nonce too high", immediately re-sync from RPC and pause higher-nonce submissions; ask your provider to minimize the Nitro hold window so errors surface immediately.

## Summary

| Task                  | Layer      | Source                                                         |
| --------------------- | ---------- | -------------------------------------------------------------- |
| Initial nonce         | Blockchain | `client.getTransactionCount({ address, blockTag: "pending" })` |
| Cached nonce          | Local      | `localStorage`                                                 |
| Increment between txs | Local      | `nonce + 1`                                                    |
| Sync periodically     | Remote     | `fetchOnChainNonce()`                                          |

By combining local caching and on-chain syncing, your dApp can reliably manage nonces even in complex transaction flows.