Add to Wallet
Last updated
Last updated
This guide is intended for wallet developers who want to give their users the ability to send transactions on the Patex network. Patex generally behaves like any other EVM-based chain with the exception of minor discrepancies related to transaction fees. These fee discrepancies are an inherent result of the fact that Patex is a Layer 2 blockchain network that must publish transaction data to Ethereum.
Patex shares the with only a few minor differences. You'll find all of the important information about each Patex network on our Networks page. You can choose to connect to Patex via our rate-limited public endpoints, private endpoints from infrastructure providers, or . Because of throughput limits, we recommend running your own node for production applications.
Network name
Patex Network
RPC URL
Chain ID
789
Currency symbol
ETH
Block explorer URL
The ERC-20 contract address for a token on Patex may be different from the address for the same token on Ethereum.
For example, looking at the PUT-1 token, we get these addresses:
5
Sepolia (test network)
0x04459A4D7d1d7BFb48EBc635e30169D50D56EEAC
471100
Patex Sepolia (test network)
0xCddD6D3d4024535CceeA408EAb8cd00C8f162e6D
To get the total PUT-1 balance of a user that uses Patex you need to:
Connect to a standard Ethereum endpoint and send a balanceOf query to address 0x04459A4D7d1d7BFb48EBc635e30169D50D56EEAC.
Connect to an Patex endpoint and send a balanceOf query to address 0xCddD6D3d4024535CceeA408EAb8cd00C8f162e6D.
A transaction in Patex can be in one of two states:
Sequencer Confirmed: The transaction has been accepted by the sequencer on Patex (L2)
Confirmed Onchain: The transaction has been written to Ethereum (L1)
We're still working on the tooling to easily detect when a given transaction has been published to Ethereum. For the moment, we recommend wallets consider transactions final after they are "Sequencer Confirmed". Transactions are considered "Sequencer Confirmed" as soon as their transaction receipt shows at least one confirmation.
We aim to be EVM equivalent, meaning we aim to minimize the differences between Patex and Ethereum. You can see a summary of the few differences between Patex and Ethereum here. One of the most important discrepancies can be found within Patex fee model. As a wallet developer, you must be aware of this difference.
Most of the cost of a transaction on Patex comes from the cost of publishing the transaction to Ethereum. This publication step is what makes Patex a Layer 2 blockchain. Unlike with the standard execution gas fee, users cannot specify a particular gas price or gas limit for this portion of their transaction cost. Instead, this fee is automatically deducted from the user's ETH balance on Patex when the transaction is executed.
We highly recommend displaying fees on Patex as one unified fee to minimize user confusion. You can do this by combining both portions of the fee (the L2 execution fee and the L1 data fee) into a single value presented to the end user.
Many wallets allow users to send the maximum amount of ETH available in the user's balance. Of course, this requires that the predicted fee for the send transaction be deducted from the ETH balance being sent. You MUST deduct both the L2 execution fee and the L1 data fee or the charged fee plus the balance sent will exceed the user's balance and the transaction will fail.
If you want to display the current gas prices, you can use the rollup_gasPrices RPC method prior to Patex, or eth_gasPrice in Patex.
You can read more about this subject here, or use this . The total fee paid by a transaction will be a combination of the normal fee estimation formula (gasPrice * gasLimit) in addition to the estimated L1 fee.