---
title: 'Migrate Your EVM dApp to Paxeer'
sidebarTitle: 'Migrate from Other EVMs'
description: 'Step-by-step checklist for redeploying your EVM dApp on Paxeer from Ethereum, Arbitrum, Base, Polygon, or Avalanche.'
keywords: ['EVM migration', 'cross-chain deployment', 'ethereum to paxeer', 'arbitrum to paxeer', 'base to paxeer', 'polygon to paxeer', 'avalanche to paxeer', 'smart contract deployment']
---

> **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version.

Paxeer offers full EVM bytecode compatibility with fast finality and high throughput. This guide distills what product teams need to do when they already run on Polygon, Base, Ethereum, Arbitrum, Avalanche or another EVM chain and want to bring your dApp stack to Paxeer.

<Info>
**Why Migrate to Paxeer?**

- **Fast block times** - Sub-second blocks for rapid transaction inclusion
- **High throughput** - Designed for demanding workloads without sacrificing EVM compatibility
- **Instant finality** - No waiting for confirmations or safe/finalized states
- **Full EVM compatibility** - Deploy your existing Solidity contracts unchanged

</Info>

## Chain Comparison Overview

Before diving into migration steps, understand how Paxeer compares to your source chain:

| Feature | Paxeer | Ethereum | Arbitrum | Base | Polygon PoS | Avalanche C-Chain |
| --- | --- | --- | --- | --- | --- | --- |
| Chain ID | 125 | 1 | 42161 | 8453 | 137 | 43114 |
| Finality | Instant | ~15 min (finalized) | ~7 days (L1 settlement) | ~7 days (L1 settlement) | ~5 s (Heimdall v2) | ~1 s |
| Native Token | HPX | ETH | ETH | ETH | POL (MATIC) | AVAX |
| EVM Version | Pectra | Fusaka | Fusaka | Pectra | Pectra | Cancun |


## Chain-Specific Migration Guides

Select your source chain to see specific migration considerations:

<Tabs>
  <Tab title="Ethereum">

### Migrating from Ethereum Mainnet

**Key Differences:**

| Aspect | Ethereum | Paxeer | Migration Impact |
| --- | --- | --- | --- |
| Block time | ~12 seconds | Sub-second | Reduce `deadline` buffers in DEX swaps |
| Finality | ~15 min for finalized | Instant | Remove confirmation polling logic |
| Fee model | EIP-1559 with burn | EIP-1559 different params | Update fee estimation UIs |
| Pending state | Yes | No | Remove pending transaction logic |


**What to Update:**

1. **Time-based logic:** If your contracts use block timestamps for deadlines, reduce timeouts proportionally.

2. **Confirmation requirements:** Remove any logic that waits for multiple confirmations or checks "safe" vs "finalized" states - Paxeer has instant finality.

3. **Gas estimation:** Paxeer's execution environment can slightly vary gas estimates. Add a modest buffer (10-15%) to your `gasLimit` calculations.

4. **Fee UI:** Simplify your frontend - you can use a single `gasPrice` input instead of `maxFeePerGas` / `maxPriorityFeePerGas`.

```ts
// Before (Ethereum EIP-1559)
const tx = await contract.method({
  maxFeePerGas: ethers.parseUnits('50', 'gwei'),
  maxPriorityFeePerGas: ethers.parseUnits('2', 'gwei')
});

// After (Paxeer - simplified)
const tx = await contract.method({
  gasPrice: ethers.parseUnits('50', 'gwei')
});
```

5. **PREVRANDAO/DIFFICULTY:** If you use these for any randomness, integrate a VRF oracle instead - Paxeer's values are derived from block time, not true randomness.

  </Tab>
  <Tab title="Arbitrum">

### Migrating from Arbitrum

**Key Differences:**

| Aspect | Arbitrum | Paxeer | Migration Impact |
| --- | --- | --- | --- |
| Architecture | Optimistic Rollup (L2) | L1 | No L1 data availability concerns |
| Finality | ~7 days for L1 settlement | Instant | Simplify withdrawal flows |
| Sequencer | Centralized sequencer | Decentralized validators | No sequencer downtime risk |
| L1 gas | Pays L1 data costs | No L1 dependency | Simpler fee structure |


**What to Update:**

1. **Remove L1 interactions:** Any logic that posts data to or reads from Ethereum L1 should be removed or replaced with Paxeer-native alternatives.

2. **Sequencer assumptions:** Remove any sequencer uptime checks or fallback logic - Paxeer uses decentralized consensus.

3. **Withdrawal delays:** If your protocol has 7-day withdrawal windows for "L1 finality," you can remove these - Paxeer settles instantly.

4. **ArbOS precompiles:** Replace any Arbitrum-specific precompiles:

```solidity
// Arbitrum-specific (remove)
// import { ArbSys } from "@arbitrum/nitro-contracts/src/precompiles/ArbSys.sol";
// uint256 blockNum = ArbSys(0x64).arbBlockNumber();

// Paxeer equivalent
uint256 blockNum = block.number; // Standard EVM
```

5. **Cross-chain messaging:** Replace Arbitrum's native bridge with [LayerZero V2](/evm) for omnichain connectivity.

  </Tab>
  <Tab title="Base">

### Migrating from Base

**Key Differences:**

| Aspect | Base | Paxeer | Migration Impact |
| --- | --- | --- | --- |
| Architecture | OP Stack Rollup (L2) | L1 | No L1 data availability concerns |
| Finality | ~7 days for L1 settlement | Instant | Simplify withdrawal flows |
| Sequencer | Coinbase-operated | Decentralized validators | No single point of failure |
| EIP-4844 blobs | Supported | Not supported | Remove blob transaction logic |


**What to Update:**

1. **Remove blob transactions:** Paxeer doesn't support EIP-4844 blob transactions. If you're using them for data availability, store data differently or use Paxeer's native mechanisms.

2. **OP Stack precompiles:** Remove any Optimism/Base-specific precompile calls:

```solidity
// Base-specific (remove)
// L1Block(0x4200000000000000000000000000000000000015).number();

// Use standard EVM on Paxeer
uint256 blockNum = block.number;
```

3. **Fault proof assumptions:** Remove any logic that accounts for the 7-day challenge period - Paxeer has instant finality.

4. **Sequencer fee logic:** Base has a separate L1 data fee component. On Paxeer, fees are simpler: `Gas Used × Gas Price`.

5. **Coinbase Wallet integrations:** Update wallet connection logic to use Paxeer network parameters:

```ts
// Update network config
const paxeerMainnet = {
  chainId: '0x7d', // 125 in hex
  chainName: 'Paxeer',
  nativeCurrency: { name: 'Paxeer', symbol: 'HPX', decimals: 18 },
  rpcUrls: ['https://public-rpc.paxeer.app/evm/reference'],
  blockExplorerUrls: ['https://paxscan.io']
};
```

  </Tab>
  <Tab title="Polygon">

### Migrating from Polygon PoS

**Key Differences:**

| Aspect | Polygon PoS | Paxeer | Migration Impact |
| --- | --- | --- | --- |
| Native token | POL (MATIC) | HPX | Update all token references |
| Finality | ~5 s (Heimdall v2) | Instant | Remove finality delay handling |
| Checkpoints | Periodic to Ethereum | None | Simpler architecture |
| Reorgs | Possible (rare) | Never | Remove reorg handling |


**What to Update:**

1. **Token references:** Replace all MATIC/POL references with HPX:

```solidity
// Before (Polygon)
// IERC20(0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270).transfer(...); // WMATIC

// After (Paxeer) - use native HPX or wrapped version
// Check ecosystem contracts for canonical WHPX address
```

2. **Checkpoint logic:** Remove any logic that waits for Polygon checkpoints to Ethereum - Paxeer has instant finality.

3. **Heimdall/Bor assumptions:** Remove any Polygon-specific validator or sidechain logic.

4. **Reorg handling:** You can safely remove block reorganization handling code - Paxeer's consensus prevents reorgs.

5. **Gas price oracles:** Polygon's gas prices can spike significantly. Paxeer's fees are more stable:

```ts
// Polygon - needed aggressive gas price management
const gasPrice = await provider.getGasPrice();
const boostedPrice = gasPrice.mul(120).div(100); // 20% buffer

// Paxeer - simpler approach works
const gasPrice = await provider.getGasPrice(); // Usually sufficient as-is
```

6. **Bridge integrations:** Replace Polygon Bridge with [LayerZero](/evm) or other Paxeer-supported bridges.

  </Tab>
  <Tab title="Avalanche">

### Migrating from Avalanche C-Chain

**Key Differences:**

| Aspect | Avalanche C-Chain | Paxeer | Migration Impact |
| --- | --- | --- | --- |
| Native token | AVAX | HPX | Update all token references |
| Finality | ~1 second | Instant | Similar, slightly faster |
| Subnets | Supported | N/A | Remove subnet logic |


**What to Update:**

1. **Token references:** Replace AVAX with HPX:

```solidity
// Before (Avalanche)
// IERC20(0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7).transfer(...); // WAVAX

// After (Paxeer)
// Use native HPX or check ecosystem contracts for WHPX
```

2. **Subnet interactions:** If your dApp uses Avalanche Subnets, you'll need to redesign that architecture for Paxeer's single-chain model or use cross-chain messaging.

3. **Avalanche-specific precompiles:** Remove C-Chain precompile calls:

```solidity
// Avalanche-specific (remove)
// INativeMinter(0x0200000000000000000000000000000000000001).mintNativeCoin(...)

// Use standard EVM patterns on Paxeer
```

4. **TWAP calculations:** Both chains have fast blocks, but adjust your observation windows if migrating oracle logic.

  </Tab>
</Tabs>

## Step 1: Evaluate Compatibility

Revisit the [Divergence from Ethereum](/evm/differences-with-ethereum) doc and confirm every assumption your contracts/frontends make still holds.

| Dimension | Paxeer EVM | Practical Effect |
| --- | --- | --- |
| Finality | Instant | No separate "safe/latest" commitment levels to poll |
| Base fee | Dynamic but not burned | Validators receive 100% of fees |
| Execution | Full EVM compatibility | No changes to your Solidity code are necessary |
| Address format | Dual (0x + pax1...) | Same private key derives both addresses |


<Warning>

**Features Requiring Attention:**

- **Pending state:** Paxeer doesn't have pending state - transactions are either included or not
- **Blob opcodes:** EIP-4844 blob transactions are not supported
- **PREVRANDAO entropy:** Returns block-time-derived value, not true randomness - use VRF oracles here
- **SELFDESTRUCT:** Deprecated; refactor to "soft close" patterns

</Warning>

## Step 2: Prepare Your Development Environment

### Add Paxeer Network Configuration

**Hardhat Configuration:**

```ts title="hardhat.config.ts"
import { defineConfig, configVariable } from 'hardhat/config';
import hardhatToolboxMochaEthers from '@nomicfoundation/hardhat-toolbox-mocha-ethers';

export default defineConfig({
  networks: {
    paxeerMainnet: {
      type: 'http',
      chainId: 125,
      url: 'https://public-rpc.paxeer.app/evm/reference',
      accounts: [configVariable('PAXEER_PRIVATE_KEY')]
    }
  },
  plugins: [hardhatToolboxMochaEthers]
});
```

Store your deployer key in Hardhat's encrypted keystore with `npx hardhat keystore set PAXEER_PRIVATE_KEY`. Contract verification via Sourcify is enabled by default in Hardhat 3's `hardhat-verify` (bundled with the toolbox).

**Foundry Configuration:**

```toml title="foundry.toml"
[profile.default]
src = "src"
out = "out"
libs = ["lib"]

[rpc_endpoints]
paxeer_mainnet = "https://public-rpc.paxeer.app/evm/reference"

# Verification uses Sourcify (no API key needed)
# Run: forge verify-contract --verifier sourcify --chain-id 125 <ADDRESS> <PATH:CONTRACT>
```

See the [Hardhat tutorial](/evm/evm-hardhat) and [Foundry guide](/evm/evm-foundry) for complete setup instructions.

### Wallet Configuration

Pre-configure MetaMask or other wallets with Paxeer chain params:

```ts
const paxeerMainnet = {
  chainId: '0x7d', // 125
  chainName: 'Paxeer',
  nativeCurrency: { name: 'Paxeer', symbol: 'HPX', decimals: 18 },
  rpcUrls: ['https://public-rpc.paxeer.app/evm/reference'],
  blockExplorerUrls: ['https://paxscan.io']
};

await window.ethereum.request({
  method: 'wallet_addEthereumChain',
  params: [paxeerMainnet]
});
```

## Step 3: Bootstrap Common Infrastructure

Paxeer already exposes canonical helper contracts - reference them instead of redeploying:

| Component | Address | Notes |
| --- | --- | --- |
| Permit2 | `0xB952578f3520EE8Ea45b7914994dcf4702cEe578` | Shared allowance manager for DEX and wallet flows |
| Multicall3 | `0xcA11bde05977b3631167028862bE2a173976CA11` | Enables batching and view aggregation |
| ImmutableCreate2Factory | `0x0000000000FFe8B47B3e2130213B802212439497` | Deterministic deployments with `CREATE2` |
| SingletonFactory | `0xce0042B868300000d44A59004Da54A005ffdcf9f` | EIP-2470 singleton factory |


For third-party contracts (LayerZero, Safe, etc.), consult the full [Ecosystem Contracts page](/evm/ecosystem-contracts).

## Step 4: Port Contracts and Configuration

### Parameterize Chain-Specific Constants

```solidity
// Example: Chain-aware deadline calculation
function getDeadline(uint256 secondsFromNow) internal view returns (uint256) {
    if (block.chainid == 125) { // Paxeer mainnet
        return block.timestamp + secondsFromNow;
    } else if (block.chainid == 1) { // Ethereum
        return block.timestamp + secondsFromNow;
    }
    return block.timestamp + secondsFromNow;
}
```

### Adjust Gas and Size Assumptions

- Keep `gasLimit` buffers modest but ensure calldata stays under the block limit
- Large deployments may need batching

### Refactor Deprecated Patterns

```solidity
// Before: SELFDESTRUCT (deprecated)
function destroy() external onlyOwner {
    selfdestruct(payable(owner));
}

// After: Soft close pattern
bool public closed;

function close() external onlyOwner {
    closed = true;
    // Transfer remaining funds
    payable(owner).transfer(address(this).balance);
}

modifier notClosed() {
    require(!closed, "Contract is closed");
    _;
}
```

## Step 5: Plan Bridging and Cross-Chain Connectivity

### LayerZero V2

See the complete [LayerZero integration guide](/evm).

```ts title="layerzero.config.ts"
import { EndpointId } from '@layerzerolabs/lz-definitions';

const paxeerContract = {
  eid: EndpointId.PAXEER_V2_MAINNET,
  contractName: 'MyOFT'
};
```

### Other Bridge Options

- **Circle CCTP:** For USDC bridging (check availability)

## Step 6: Handle Assets and Oracles

### Oracle Integration

Paxeer supports multiple oracle solutions:

| Provider | Use Case | Documentation |
| --- | --- | --- |
| Pyth Network | High-frequency price feeds | [Pyth Network](https://docs.pyth.network/) |
| Chainlink | Industry-standard data feeds | [Chainlink on Paxeer](/evm) |
| RedStone | Modular oracle with push model | [RedStone on Paxeer](/evm) |
| API3 | First-party oracle data | [API3 on Paxeer](/evm) |


## Step 7: Launch Checklist

### Mainnet Deployment (chain ID 125)

- [ ] Deploy contracts to mainnet (chain ID: `125`)
- [ ] Run full integration test suite
- [ ] Verify contracts via [Sourcify](/evm/evm-verify-contracts)
- [ ] Test wallet connections and transaction flows
- [ ] Validate oracle integrations
- [ ] Test cross-chain messaging if applicable
- [ ] Re-run smoke tests
- [ ] Update frontend configurations
- [ ] Prepare user migration documentation

<Warning>**Fee Redistribution Warning:** Fees on Paxeer are not burned. If your protocol redistributes "burn rebates" to users, redesign that logic so it does not expect a base-fee burn component.</Warning>

## Step 8: Operational Readiness

### Contract Verification

Automate verification through CI using [Sourcify](/evm/evm-verify-contracts):

```bash
# Foundry verification
forge verify-contract --watch \
  --verifier sourcify \
  --chain-id 125 \
  <CONTRACT_ADDRESS> \
  <CONTRACT_NAME>
```

### RPC and Indexer Health

- **Primary RPC:** `https://public-rpc.paxeer.app/evm/reference`
- For mission-critical paths, consider self-hosted nodes or [premium RPC providers](/learn/dev-chains)

### Monitoring Gas Parameters

Periodically query fee data to keep dashboards aligned:

```ts
// Monitor current gas prices
const feeHistory = await provider.send('eth_feeHistory', ['0x5', 'latest', []]);
const gasPrice = await provider.getGasPrice();
```

## Helpful References

- [Divergence from Ethereum](/evm/differences-with-ethereum) - Opcode, gas, and state nuances
- [EVM Networks](/evm/networks) - RPCs, explorers, and MetaMask payloads
- [Precompiles](/evm/precompiles/example-usage) - Interoperability patterns
- [Ecosystem Contracts](/evm/ecosystem-contracts) - Canonical addresses
- [LayerZero Integration](/evm) - Cross-chain messaging
- [Contract Verification](/evm/evm-verify-contracts) - Contract verification guide