Advanced Usage

# Advanced Usage
## Custom Gas Parameters
## Custom Nonce Management
## Additional Customization
## Next Steps

This section covers advanced customization options for your UserOperations.

## Custom Gas Parameters

You can customize gas parameters for your UserOperations:

```typescript
// Set specific gas values
builder.setCallGasLimit("0x88b8");
builder.setVerificationGasLimit("0x33450");
builder.setPreVerificationGas("0xc350");
builder.setMaxFeePerGas("0x2162553062");
builder.setMaxPriorityFeePerGas("0x40dbcf36");
```

## Custom Nonce Management

If needed, you can manually set the nonce for your UserOperations:

```typescript
// Get the current nonce
const aaWallet = new ethers.Contract(
  aaWalletAddress,
  ['function getNonce() view returns (uint256)'],
  accountSigner
);
const nonce = await aaWallet.getNonce();

// Set a custom nonce
builder.setNonce(nonce.add(1));
```

## Additional Customization

Beyond gas parameters and nonce management, you can also:

- Customize the signature mechanism
- Implement your own account abstraction logic
- Create custom presets for specific use cases

## Next Steps

After learning about advanced customization options, you might want to:
- [Learn about error handling](https://docs.nerochain.io/en/developer-tools/user-op-sdk/error-handling)
- [Review best practices](https://docs.nerochain.io/en/developer-tools/user-op-sdk/best-practices)


Installation and Basic Usage

# Installation and Basic Usage
## Installation
## Basic Usage
### Importing the SDK
### Configuration Constants
### Initializing the Client
### Creating a SimpleAccount Builder
## Next Steps

## Installation

You can install the UserOpSDK directly from GitHub:

```bash
npm install github:nerochain/aa-userop-sdk
```

Or using yarn:

```bash
yarn add github:nerochain/aa-userop-sdk
```

## Basic Usage

This section covers the essential steps to start using the UserOpSDK.

### Importing the SDK

```typescript

```

### Configuration Constants

Set up your configuration with the necessary contract addresses and service endpoints:

```typescript
// Chain configuration
const NERO_RPC_URL = "https://rpc-testnet.nerochain.io";
const BUNDLER_URL = "https://bundler-testnet.nerochain.io/";
const PAYMASTER_URL = "https://paymaster-testnet.nerochain.io";

// Contract addresses
const ENTRYPOINT_ADDRESS = "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789";
const ACCOUNT_FACTORY_ADDRESS = "0x9406Cc6185a346906296840746125a0E44976454";
```

### Initializing the Client

```typescript
// Initialize the AA Client
const client = await Client.init(NERO_RPC_URL, {
  overrideBundlerRpc: BUNDLER_URL,
  entryPoint: ENTRYPOINT_ADDRESS,
});
```

### Creating a SimpleAccount Builder

The SimpleAccount builder helps you create and configure UserOperations:

```typescript
// accountSigner is the EOA wallet that will own the AA wallet
const builder = await Presets.Builder.SimpleAccount.init(
  accountSigner,
  NERO_RPC_URL,
  {
    overrideBundlerRpc: BUNDLER_URL,
    entryPoint: ENTRYPOINT_ADDRESS,
    factory: ACCOUNT_FACTORY_ADDRESS,
  }
);
```

## Next Steps

Now that you've installed, initialized the client and builder, you can:
- [Work with AA Wallets](https://docs.nerochain.io/en/developer-tools/user-op-sdk/working-with-wallets)
- [Create UserOperations](https://docs.nerochain.io/en/developer-tools/user-op-sdk/creating-user-operations)


Best Practices

Follow these best practices to optimize your use of the UserOpSDK in production applications.

## 1. Cache AA Wallet Addresses

Calculate and store AA wallet addresses to avoid redundant computation:

```typescript
// Calculate once and store in your database or local storage
const aaWalletAddress = await builder.getSender();
```

## 2. Implement Comprehensive Error Handling

Handle all potential errors gracefully to improve user experience:

```typescript
try {
  const result = await client.sendUserOperation(builder);
  // Success path
} catch (error) {
  // Categorize and handle different error types
  if (error.message.includes('AA21')) {
    // Handle insufficient funds
  } else if (error.message.includes('AA31')) {
    // Handle paymaster validation error
  } else {
    // Generic error handling
  }
}
```

## 3. Gas Estimation

For complex operations, use gas estimation functions to ensure sufficient gas:

```typescript
// Estimate gas before sending
const gasEstimation = await client.estimateUserOperationGas(builder);
builder.setCallGasLimit(gasEstimation.callGasLimit);
builder.setVerificationGasLimit(gasEstimation.verificationGasLimit);
builder.setPreVerificationGas(gasEstimation.preVerificationGas);
```

## 4. Test on Testnet

Always test your implementation on NERO Chain's testnet before deploying to mainnet:

```typescript
// Testnet configuration
const NERO_TESTNET_RPC_URL = "https://rpc-testnet.nerochain.io";
const TESTNET_BUNDLER_URL = "https://bundler-testnet.nerochain.io";
const TESTNET_PAYMASTER_URL = "https://paymaster-testnet.nerochain.io";
```

## 5. Security

Never store private keys or API keys in client-side code:

```typescript
// BAD: Hardcoded API key
const PAYMASTER_API_KEY = "your-api-key"; // Don't do this!

// GOOD: Load from environment variables on the server
const PAYMASTER_API_KEY = process.env.PAYMASTER_API_KEY;
```

## Additional Resources

For more details and advanced use cases, refer to the following resources:
- [ERC-4337 Specification](https://eips.ethereum.org/EIPS/eip-4337)
- [UserOpSDK GitHub Repository](https://github.com/nerochain/aa-userop-sdk)


Creating UserOperations

# Creating UserOperations
## Understanding Minimal UserOperations
## Simple Token Transfer
## Executing Multiple Transactions
## Next Steps

This part walks over how to use the SDK to produce various kinds of UserOperations.

## Understanding Minimal UserOperations

User operations have a standard structure, hence it's crucial to know before starting certain transactions. A simple user operation includes all necessary fields even with placeholder values:

```typescript
// Create a minimal UserOp
const minimalUserOp = {
  sender: aaWalletAddress, // The AA wallet address
  nonce: "0x0",            // Will be filled by the SDK or custom logic
  initCode: "0x",          // Empty for existing wallets
  callData: "0x",          // Will be filled with actual transaction data
  callGasLimit: "0x0",     // Gas estimation
  verificationGasLimit: "0x0",
  preVerificationGas: "0x0",
  maxFeePerGas: "0x0",
  maxPriorityFeePerGas: "0x0",
  paymasterAndData: "0x",  // Will be filled by Paymaster integration
  signature: "0x"          // Will be filled with EOA signature
};
```

This minimal structure is useful for:
- Making RPC calls that require a UserOperation structure
- Initializing a UserOperation before filling in specific details
- Testing and debugging
- Interacting with services like the Paymaster API

The UserOpSDK will handle filling in most of these fields automatically, but understanding this structure is helpful when working with the SDK and developing your own utilities.

## Simple Token Transfer

To perform a simple ERC-20 token transfer, you'll start with the builder created in the [Basic Usage](https://docs.nerochain.io/en/developer-tools/user-op-sdk/basic-usage) section and add your specific transaction:

```typescript
// 1. Start with the builder from previous setup
// const builder = await Presets.Builder.SimpleAccount.init(...);

// 2. Create an ERC-20 contract instance
const tokenContract = new ethers.Contract(
  tokenAddress,
  ['function transfer(address to, uint256 amount) returns (bool)'],
  accountSigner
);

// 3. Prepare the call data for transfer
const callData = tokenContract.interface.encodeFunctionData(
  'transfer',
  [recipientAddress, ethers.utils.parseUnits(amount, decimals)]
);

// 4. Add the transaction to the builder
// This will incorporate the transaction into a UserOperation
builder.execute(tokenAddress, 0, callData);

// 5. The builder now contains the UserOperation with your transfer
// Under the hood, it fills in the parameters of the minimal UserOperation:
// - sender: from builder.getSender()
// - nonce: auto-retrieved from the AA wallet
// - callData: your transfer function call
// - gas parameters: estimated or set manually
```

When you call `builder.execute()`, the SDK takes care of incorporating your transaction into the UserOperation structure, eliminating the need to manually build each field of the minimal UserOperation.

## Executing Multiple Transactions

You can bundle multiple actions into a single UserOperation using the same builder pattern:

```typescript
// 1. Start with the same builder
// const builder = await Presets.Builder.SimpleAccount.init(...);

// 2. Prepare multiple call data and targets
const callData = [
  tokenContract.interface.encodeFunctionData('approve', [spender, amount]),
  tokenContract.interface.encodeFunctionData('transfer', [recipient, amount])
];
const callTo = [tokenAddress, tokenAddress];

// 3. Add batch execution to the builder
// This bundles multiple transactions into a single UserOperation
builder.executeBatch(callTo, callData);

// 4. The builder now contains a UserOperation with multiple actions
// The single UserOperation will:
// - Approve tokens to be spent by another address
// - Transfer tokens to the recipient
// All in one atomic transaction
```

With the batch execution feature, multiple actions are combined into a single UserOperation's `callData` field, allowing you to perform complex operations efficiently.

## Next Steps

After creating UserOperations with the builder:
- [Integrate with Paymaster](https://docs.nerochain.io/en/developer-tools/user-op-sdk/paymaster-integration) to handle gas payments
- [Send UserOperations](https://docs.nerochain.io/en/developer-tools/user-op-sdk/sending-user-operations) to the network


Error Handling

# Error Handling
## Common Error Types
## Error Code Categories
## User-Friendly Error Handling
## Next Steps

The UserOpSDK may return various errors during operation. This section covers common errors and how to handle them.

## Common Error Types

```typescript
try {
  const result = await client.sendUserOperation(builder);
  // Process result
} catch (error) {
  if (error.message.includes('AA1')) {
    console.error('error codes relate to creating an account');
    // Handle insufficient funds error
  } else if (error.message.includes('AA2')) {
    console.error('error codes relate to the sender of the user operation');
    // Handle validation error
  } else if (error.message.includes('AA3')) {
    console.error('error codes relate to paymasters');
    // Handle paymaster error
  } else if (error.message.includes('AA4')) {
    console.error('error codes relate to verification generally');
    // Handle paymaster error
  } else if (error.message.includes('AA5')) {
    console.error('errors relate to actions after the user operation was executed');
    // Handle paymaster error
  } else {
    console.error('Unknown error:', error);
    // Handle other errors
  }
}
```

## Error Code Categories

- **AA1** - Account creation errors (e.g., insufficient funds for counterfactual deployment)
- **AA2** - Sender errors (e.g., invalid signature)
- **AA3** - Paymaster errors (e.g., insufficient deposit, rejected operation)
- **AA4** - General verification errors
- **AA5** - Post-execution errors

## User-Friendly Error Handling

When building a user interface, translate technical errors into user-friendly messages:

```typescript
function getUserFriendlyErrorMessage(error) {
  if (error.message.includes('AA21')) {
    return "You don't have enough funds to pay for this transaction.";
  } else if (error.message.includes('AA23')) {
    return "The transaction signature is invalid. Please try again.";
  } else if (error.message.includes('AA25')) {
    return "The gas payment details are invalid. Please select a different payment option.";
  } else {
    return "An error occurred while processing your transaction. Please try again.";
  }
}
```

## Next Steps

After implementing error handling, you might want to:
- [Review best practices](https://docs.nerochain.io/en/developer-tools/user-op-sdk/best-practices) for using the SDK


UserOpSDK: Account Abstraction SDK

# UserOpSDK: Account Abstraction SDK
## What's Inside

Designed as a potent JavaScript/TypeScript tool, the UserOpSDK streamlines UserOperations on NERO Chain creation, signing, and transmission. This piece will assist you to use Account Abstraction capabilities in your dApp by using the SDK.

The UserOpSDK provides access to fundamental Account Abstraction functionality on NERO Chain, with capabilities such as:

- Creating UserOperations for contract calls and transfers
- Signing UserOperations with Ethereum signers
- Communicating with bundlers to execute transactions
- Integrating with Paymasters to sponsor gas or accept ERC-20 tokens
- Creating and managing smart contract wallets

This section helps you get started with the SDK and provides examples of common operations.

## What's Inside

- [Installation & Basic Usage](https://docs.nerochain.io/en/developer-tools/user-op-sdk/basic-usage) - How to install the SDK and get started
- [Working with AA Wallets](https://docs.nerochain.io/en/developer-tools/user-op-sdk/working-with-wallets) - Getting wallet addresses and checking deployment status
- [Creating UserOperations](https://docs.nerochain.io/en/developer-tools/user-op-sdk/creating-user-operations) - Creating simple and batch operations
- [Paymaster Integration](https://docs.nerochain.io/en/developer-tools/user-op-sdk/paymaster-integration) - Setting API keys, getting supported tokens, and payment types
- [Sending UserOperations](https://docs.nerochain.io/en/developer-tools/user-op-sdk/sending-user-operations) - How to submit operations to the network
- [Advanced Usage](https://docs.nerochain.io/en/developer-tools/user-op-sdk/advanced-usage) - Custom gas parameters and nonce management
- [Error Handling](https://docs.nerochain.io/en/developer-tools/user-op-sdk/error-handling) - Common errors and how to handle them
- [Best Practices](https://docs.nerochain.io/en/developer-tools/user-op-sdk/best-practices) - Tips for optimal SDK usage


Paymaster Integration

# Paymaster Integration
## Setting API Key for Paymaster
## Getting Supported Tokens
## Setting Payment Type
## Next Steps

The Paymaster service allows for flexible gas payment options for UserOperations.

## Setting API Key for Paymaster

To use the Paymaster service, set your API key:

```typescript
builder.setPaymasterOptions({
  apikey: YOUR_API_KEY,
  rpc: PAYMASTER_URL
});
```

## Getting Supported Tokens

The SDK doesn't include a built-in method for retrieving supported tokens. You need to make a direct RPC call to the Paymaster API:

```typescript
// Create a helper function to get supported tokens
async function getSupportedTokens(client, builder) {
  try {
    // Get the wallet address
    const sender = await builder.getSender();

    // Create a minimal UserOp for the request
    const minimalUserOp = {
      sender,
      nonce: "0x0",
      initCode: "0x",
      callData: "0x",
      callGasLimit: "0x0",
      verificationGasLimit: "0x0",
      preVerificationGas: "0x0",
      maxFeePerGas: "0x0",
      maxPriorityFeePerGas: "0x0",
      paymasterAndData: "0x",
      signature: "0x"
    };

    // Setup the provider for the paymaster RPC
    const provider = new ethers.providers.JsonRpcProvider(PAYMASTER_URL);

    // Call the pm_supported_tokens method
    const tokensResponse = await provider.send("pm_supported_tokens", [
      minimalUserOp,
      YOUR_API_KEY,
      ENTRYPOINT_ADDRESS
    ]);

    // Parse and return the token list
    if (tokensResponse && tokensResponse.tokens) {
      return tokensResponse.tokens.map(token => ({
        address: token.token || token.address,
        decimals: token.decimals,
        symbol: token.symbol,
        type: token.type
      }));
    }

    return [];
  } catch (error) {
    console.error("Error getting supported tokens:", error);
    return [];
  }
}

// Usage
const supportedTokens = await getSupportedTokens(client, builder);
console.log("Supported tokens:", supportedTokens);
```

Different Paymaster implementations may return tokens in different formats. A more robust implementation would include handling for various response formats as shown in this example:

```typescript
// Handle different response formats
let tokens = [];
if (tokensResponse.tokens) {
  tokens = tokensResponse.tokens;
} else if (Array.isArray(tokensResponse)) {
  tokens = tokensResponse;
} else if (typeof tokensResponse === 'object') {
  // Try to find tokens in the response object
  const possibleTokensArray = Object.values(tokensResponse).find(val => Array.isArray(val));
  if (possibleTokensArray && Array.isArray(possibleTokensArray)) {
    tokens = possibleTokensArray;
  }
}
```

## Setting Payment Type

Configure how users will pay for gas:

```typescript
// Type 0: Free gas (developer sponsors)
builder.setPaymasterOptions({
  type: 0,
  apikey: YOUR_API_KEY,
  rpc: PAYMASTER_URL
});

// Type 1: Prepay with ERC20 tokens
builder.setPaymasterOptions({
  type: 1,
  token: TOKEN_ADDRESS, // The ERC20 token address
  apikey: YOUR_API_KEY,
  rpc: PAYMASTER_URL
});

// Type 2: Postpay with ERC20 tokens
builder.setPaymasterOptions({
  type: 2,
  token: TOKEN_ADDRESS, // The ERC20 token address
  apikey: YOUR_API_KEY,
  rpc: PAYMASTER_URL
});
```

## Next Steps

After configuring the Paymaster for your UserOperation, you can:
- [Send UserOperations](https://docs.nerochain.io/en/developer-tools/user-op-sdk/sending-user-operations) to the network
- [Explore advanced options](https://docs.nerochain.io/en/developer-tools/user-op-sdk/advanced-usage) for customization


Sending UserOperations

# Sending UserOperations
## Sending the UserOperation
## Monitoring UserOperation Status
## Next Steps

Once your UserOperation is configured, you can send it to the network. This section covers the process of sending operations and handling the results.

## Sending the UserOperation

```typescript
try {
  // Send the UserOperation
  const result = await client.sendUserOperation(builder);

  // Get the transaction hash
  const userOpHash = result.userOpHash;
  console.log("UserOperation hash:", userOpHash);

  // Wait for the transaction to be mined
  const receipt = await result.wait();
  console.log("Transaction hash:", receipt.transactionHash);

  return receipt;
} catch (error) {
  console.error("Error sending UserOperation:", error);
  throw error;
}
```

## Monitoring UserOperation Status

After sending a UserOperation, you can monitor its status:

1. First, you get the `userOpHash` from the result of `sendUserOperation`.
2. Then, you can use `wait()` on the result to wait for the operation to be included in a block.
3. The receipt contains the transaction hash that can be used to look up details on a block explorer.

## Next Steps

After sending UserOperations, you might want to:
- [Explore advanced options](https://docs.nerochain.io/en/developer-tools/user-op-sdk/advanced-usage) for customization
- [Learn about error handling](https://docs.nerochain.io/en/developer-tools/user-op-sdk/error-handling) for better user experience


Working with AA Wallets

# Working with AA Wallets
## Getting the AA Wallet Address
## Checking AA Wallet Deployment Status
## Next Steps

Account Abstraction wallets are deterministically generated for each EOA wallet. This section covers how to work with these AA wallets.

## Getting the AA Wallet Address

Each EOA wallet has a corresponding AA wallet address that's deterministically generated:

```typescript
// Get the AA wallet address (works even if not yet deployed on-chain)
const aaWalletAddress = await builder.getSender();
console.log("AA Wallet Address:", aaWalletAddress);
```

## Checking AA Wallet Deployment Status

You can check if an AA wallet has already been deployed:

```typescript
const provider = new ethers.providers.JsonRpcProvider(NERO_RPC_URL);
const code = await provider.getCode(aaWalletAddress);
const isDeployed = code !== '0x';
console.log("Wallet deployed:", isDeployed);
```

## Next Steps

After working with AA wallet addresses, you can:
- [Create UserOperations](https://docs.nerochain.io/en/developer-tools/user-op-sdk/creating-user-operations)
- [Integrate with Paymaster](https://docs.nerochain.io/en/developer-tools/user-op-sdk/paymaster-integration)


Frequently Asked Questions

This FAQ answers common challenges, pitfalls, and questions that developers may have when building on NERO Chain.

## Account Abstraction

### What exactly is Account Abstraction?
Account Abstraction (AA) is a paradigm that allows smart contract wallets to execute transactions without users needing to hold the native token (NERO) for gas fees. Account Abstraction (AA) is a paradigm that allows smart contract wallets to execute transactions without users needing to hold the native token (NERO) for gas fees. It lets features like transaction sponsorship, batch transactions, and complex authorizing methods isolate the account management logic from transaction validation.

### Why do my UserOperations keep getting rejected?
UserOperations might be rejected for several reasons:
- **Invalid signature**: Ensure you're using the correct signer for the wallet
- **Insufficient gas**: Try increasing gas limits or using the SDK's gas estimation functions
- **Paymaster rejections**: Check if your Paymaster API key is valid and has sufficient funding. Check if the APIKey has enough Remaining Requests. If it runs out of requests, please enter in contact with NERO team.
- **Nonce issues**: Ensure you're using the correct nonce for the account
- **Validation failures**: Smart contract wallet might reject operations that don't meet its requirements

### How do I debug AA error codes?
Error codes follow a pattern where:
- **AA1** codes relate to creating an account (e.g., insufficient funds for deployment)
- **AA2** codes relate to the sender (e.g., invalid signature)
- **AA3** codes relate to paymasters (e.g., insufficient deposit)
- **AA4** codes relate to general verification failures
- **AA5** codes relate to post-execution issues

## Paymaster Integration

### Why are my sponsored transactions failing?
Common reasons for paymaster failures include:
- **API Key rate limiting**: Check your key's usage patterns and consider increasing limits
- **Strategy rejection**: Verify your strategy parameters match your application's needs
- **Insufficient funds**: Ensure your sponsorship account has adequate funds for Type 0 strategies
- **User payment failure**: For Type 1/2 strategies, ensure users have sufficient token balances and have approved the paymaster contract
- **Insufficient Remaining Requests**: Check if your API has enought Remaining requests.

### What's the difference between payment strategy types?
- **Type 0 (Sponsorship)**: Gas fees are fully covered by the developer/application
- **Type 1 (ERC-20 Prepayment)**: Users pay gas in an ERC-20 token before execution
- **Type 2 (ERC-20 Postpayment)**: Users pay gas in an ERC-20 token after execution

### How do I verify which tokens are supported for gas payment?
Use the Paymaster API core functions to verify which ERC-20 tokens can be used for gas payment with the paymaster. This is particularly important for Type 1 and Type 2 payment strategies.

## Development Environment

### What networks are available for testing?
NERO Chain provides a testnet environment for development and testing:
- **Testnet RPC**: https://rpc-testnet.nerochain.io
- **Testnet Bundler**: https://bundler-testnet.nerochain.io/
- **Testnet Paymaster**: https://paymaster-testnet.nerochain.io

Always test your implementation thoroughly on testnet before deploying to mainnet.

### How do I get testnet tokens?
You can get testnet NERO tokens from the NERO Chain faucet at [app.testnet.nerochain.io/faucet](https://app.testnet.nerochain.io/faucet/).

## Security Best Practices

### What security measures should I implement?
- **Never store private keys in client-side code**: Use secure key management
- **Use environment variables for API keys**: Never hardcode API keys in your application
- **Implement gas limits**: Set appropriate gas limits to prevent excessive costs
- **Validate user inputs**: Always validate any input that will be used in transactions
- **Implement proper error handling**: Provide clear feedback to users when operations fail

### How do I protect my Paymaster API key?
Your Paymaster API key should be treated as a sensitive credential:
- Store it in environment variables, not in code
- Implement rate limiting and monitoring to detect abuse
- Regularly rotate your API keys for enhanced security

## Smart Contract Deployment

### Why is my contract deployment failing?
Common reasons for deployment failures:
- **Incorrect network configuration**: Ensure your Hardhat/Remix settings point to the correct NERO Chain RPC
- **Insufficient gas**: Try increasing the gas limit for deployment
- **Contract size limits**: Very large contracts may exceed size limits
- **Compilation errors**: Ensure your Solidity compiler version is compatible with NERO Chain

### What Solidity version should I use?
NERO Chain supports all Solidity versions that are compatible with the Ethereum London fork. We recommend using Solidity ^0.8.12 for optimal compatibility and security.

**Important**: For contract verification on Neroscan, please ensure you use Solidity version ≤ 0.8.29. Due to various factors including EVM version dependencies, Neroscan may not support newer Solidity versions in a timely manner.

### Why is my OpenZeppelin proxy contract verification failing?
OpenZeppelin proxy contracts may encounter specific verification challenges on Neroscan:

**Common Issue**: You receive an "Invalid compilerVersion" error when attempting to verify TransparentUpgradeableProxy or ProxyAdmin contracts, even though your implementation contract verifies successfully.

**Root Cause**: The block explorer's verification infrastructure has limitations with OpenZeppelin proxy contract compilation settings and version compatibility.

**Solution**:
- **Use Solidity ≤ 0.8.29**: The testnet/mainnet block explorer now supports Solidity version up to 0.8.29
- **OpenZeppelin v5 Support**: The explorer supports OpenZeppelin v5 proxy contracts that use precompiled bytecodes with Solidity 0.8.29
- **Verification Order**: Always verify your implementation contract first, then attempt proxy contract verification

**Key Points**:
- Implementation contracts typically verify without issues
- Proxy contracts (TransparentUpgradeableProxy, ProxyAdmin) require the supported Solidity versions
- Due to EVM version updates and other factors, Neroscan may not immediately support the latest Solidity versions

If you continue experiencing verification issues with proxy contracts, ensure your development environment uses Solidity 0.8.29 or earlier for both compilation and deployment.

## Wallet Integration

### Why can't I generate an AA wallet address?
Potential issues with AA wallet generation:
- **Incorrect factory address**: Verify you're using the correct account factory address
- **Salt collisions**: Try using a different salt value for address derivation
- **Chain ID mismatch**: Ensure you're using the correct chain ID for NERO Chain
- **Initialization data issues**: Verify your initialization calldata is correctly formatted

### How do I handle wallet recovery?
For AA wallets, implement recovery mechanisms like:
- Social recovery through trusted contacts
- Multi-signature requirements for certain actions
- Time-locks for security-critical operations
- Backup signers that can be activated after a delay

## Troubleshooting

### Where can I get help if I'm stuck?
If you encounter persistent issues, contact NERO Chain support through:
- [Discord Community](https://discord.gg/nerochainofficial)
- [Support Email](mailto:support@nerochain.io)
- [GitHub Issues](https://github.com/nerochain)

### How do I see if a UserOperation was processed?
You can check the status of a UserOperation using:
- The `client.getUserOperationReceipt(hash)` method in the UserOpSDK
- The NERO Chain Explorer at [neroscan.io](https://neroscan.io)
- The bundler RPC endpoint with the `eth_getUserOperationReceipt` method


# NERO Chain: What, Why, and How for Developers

## What is NERO Chain?

Fundamentally scalable, flexible, and with enhanced user experience in mind, NERO Chain is a Layer 1 modular blockchain fit for developers. NERO Chain distinguishes itself by native account abstraction (AA) and Paymaster (with an API platform for easy configuration), which helps developers create new and frictionless experiences for users while having more of their application value generated back for themselves. Developers find NERO Chain attractive due to its essential characteristics.

- **Native Account Abstraction**: Built-in support for ERC-4337 removes the need for any consensus layer modifications.
- **Paymaster System**: Allows dApps to let users pay with ERC20 tokens or sponsor gas costs entirely, with a Paymaster Platform to configure all of this on the fly.
- **Blockspace 2.0**:  By means of better transaction processing and fee distribution leveraging an effective fee-sharing system, Blockspace 2.0 guarantees effective use of network resources.
- **Complete EVM Compatibility**: No learning conflict or migration. Using familiar tools such as Solidity, Hardhat, Remix, and other popular programming environments, create and use smart contracts.

## Why Build on NERO Chain?

With a fresh perspective on blockchain technology, NERO Chain prioritizes applications over infrastructure-level value extraction.

### Applications that capture their true value

Gas, the native currency of the chain, ensures that the blockchain reaps the maximum benefit from every transaction. This leads to a system in which apps generate value, with the underlying network extracting the majority of it.

The NERO Chain introduces an economic framework that allows apps to participate in the network's success, a concept that many find upsetting. Developers may keep and share value in ways that directly benefit their users and ecosystems, therefore negating the need to turn transaction value over to the chain itself.

Through creating sustainable demand and income for their systems, developers may improve the token value by allowing gas payments using ERC20 tokens. The result means something special: If your project drives activity, so will your tokens, but with significantly more value potential.

![Simulation comparing developer token performance across chains](https://docs.nerochain.io/assets/simul.png)

*Figure 1: Simulation of developer token performance compared with other chains.*

### Seamless User Experience

User interactions' intricacy has been one of the main obstacles to blockchain acceptance. NERO Chain addresses this via:

- **Gasless Transactions**: Depending on how the application developer enables the types of payment, users can interact with dApps without owning the native token or not having tokens at all.
- **Smart Contract Wallets**: Enhanced security and recovery options compared to EOAs. We can enable social logins and much more through account abstraction.
- **Bundled Transactions**: A single transaction can execute multiple actions.

This means your applications have the tools that can onboard users who have never interacted with blockchain before, removing the friction that has historically limited Web3 adoption.
## How to Get Started with NERO Chain

With NERO Chain's EVM compatibility and developer-friendly tools, starting with its development is simple.

1. **Set Up Your Environment**: Use known tools like Hardhat, Remix, or Truffle for contract development.
2. **Access the Testnet**:  Connect to NERO Chain's Testnet for development and testing. Access the mainnet to deploy it to production.
3. **Integrate Account Abstraction**:  Use the UserOpSDK to implement AA features and connect with the Paymaster API.
4. **Leverage the Paymaster**: Enable flexible gas payment options for your users.

We will explore more in the sections below the main characteristics, architecture, and detailed instructions to let you create your first dApp on NERO Chain.


Key Features for Developers

# Key Features for Developers
## Native Account Abstraction
## Paymaster System
## Blockspace 2.0

This section provides a high-level overview of NERO Chain's key features that make it an ideal platform for developers. Knowing these characteristics will enable you to fully use NERO Chain for developing your apps.

## Native Account Abstraction

Using a native ERC-4337 Account Abstraction implementation, NERO Chain provides developers with advanced tools allowing them to construct better user experiences:

#### Smart Contract Wallets

Unlike traditional Externally Owned Accounts (EOAs), smart contract wallets on NERO Chain provide:

- **Programmable Authorization**: Implement any verification logic for transaction approval.
- **Multi-signature Support**: Require multiple signers for transaction authorization.
- **Social Recovery**: Enable account recovery through trusted friends or services.
- **Session Keys**: Implement limited-use keys for specific applications or time periods.

#### UserOperation and Bundlers

At the core of Account Abstraction is the `UserOperation` object:

- **Flexible Transaction Format**: Completely separates the user's intent from the transaction execution.
- **Bundlers**: Specialized nodes that package multiple UserOperations into a single transaction.
- **Mempool Management**: Dedicated mempool for UserOperations enhances predictability.

## Paymaster System

The Paymaster is a core component that enables flexible gas payment mechanisms. And the AA Platform gives the developer an easy-to-use way to configure everything on the fly.

#### Payment Options

- **Sponsored Transactions (Free)**: Developers can fully cover gas costs for users.
- **ERC20 Token Payments**: Users can pay gas fees using supported ERC20 tokens instead of NERO.
- **Pre-fund/Post-fund Models**: Choose between upfront payments or after-execution settlements.

![Configuring a Gas Policy](https://docs.nerochain.io/assets/aaPlatform/gifs/erc20config.gif)

*Figure 1: Configuring tokens for gas fees on the AA Platform.*

#### Integration Benefits

- **Token Utility**: Increase your token's utility by enabling it for gas payments.
- **User Experience**: Remove the need for users to own NERO tokens to interact with your dApp.
- **Flexible Pricing Models**: Implement subscription models, free trials, or per-action pricing.

## Blockspace 2.0

Regarding fees, conventional blockchain systems handle every transaction the same. With Blockspace 2.0, a breakthrough approach to controlling transaction costs and resources, NERO Chain transforms that, guaranteeing flexibility, efficiency, and justice.

#### Unique UX with Smarter Fees

- **Custom price models**: Developers may create unique price models for their particular demands, therefore matching expenses with those of their consumers.
- **Fee Sharing**: Should your dApp create transactions, users and developers stand to gain from a split of the network fees.
- **Stable Pricing**: NERO's approach seeks a more predictable charge structure than wild fluctuations in conventional gas prices.

#### Better Use of Resources
- Bundled Transactions - Consider it as carpooling for transactions; NERO arranges them to save unwarranted expenses.
- Like an express lane on a freeway, urgent transactions are handled faster in priority lanes.
- Effective resource allocation helps developers better estimate the processing power a software requires, therefore lessening surprises.

With Blockspace 2.0, NERO Chain is creating smarter, more sustainable, and better for everyone rather than only lowering costs.

![Blockspace 2.0 concept diagram](https://docs.nerochain.io/assets/block2.png)

*Figure 2: Blockspace 2.0 Architecture*


The Architecture of a dApp

Understanding NERO Chain's architecture helps us see how its unique features can be leveraged to build innovative applications with new user experiences. This overview explains how the various components work together to enable account abstraction, paymaster functionality, and other key capabilities.

Multiple components working cohesively within the distributed application (dApp) architecture ensure robust, secure, and efficient blockchain operations. Each component is explained in detail below.

![NERO Chain dApp Architecture](https://docs.nerochain.io/assets/aaPlatform/figure1.png)

*Figure 1: NERO Chain's dApp Architecture*

## Key Components and Transaction Flow

### User and Authentication Layer

The basis of NERO Chain's user experience is a flexible authentication mechanism that fits Web3 users as well as beginners alike.
Through an **AA Wallet**, a smart contract wallet supporting many simultaneous authentication techniques, the **user** interacts with blockchain functionalities. Unlike conventional wallets that depend only on private keys, NERO Chain's AA wallets may be accessible using recognizable **3rd party wallets like MetaMask**, practical **Web2 authentication** mechanisms such as Google or Twitter login, and even conventional password-based security. While keeping security and optionality for expert users, this adaptability eliminates a major obstacle to entrance for ordinary consumers.

![Aa-platform policies](https://docs.nerochain.io/assets/aaWallet/login-3.png)

*Figure 2: Example of a Social Login.*

For both owning the same on-chain identity and assets, a person may set up an AA wallet on their phone via social login but also connect to MetaMask on their PC.

### Application Components

The application layer serves as the bridge between users and the blockchain, featuring several integrated components:

The **Wallet SDK** can be the same used in any other Web3 application. Handling all the difficult chores of transaction building and submission, it serves as the interface between AA wallets and decentralized apps. It will let you get your AA wallet from the AA Wallet Factory deployed in NERO Chain.

Decentralized applications built on NERO Chain can use this architecture to provide seamless front-end interactions. Your application connects with the Wallet SDK to provide consumers with a flawless experience, whether you are developing a DEX, NFT marketplace, or gaming platform.

The Developer SDK (in our case, our **UserOpSDK**) provides developers with the tools needed to integrate account abstraction features into their applications. It covers techniques for building UserOperations, liaising with the EntryPoint contract, and using Paymasters.

By letting dApps seek gas sponsorship or alternate payment options, the **Paymaster API** helps to create gas abstraction. Your application may search the Paymaster API when a user starts a transaction to find suitable payment choices and include the required information in the UserOperation.

### Backend Infrastructure

Behind the user-facing components lies a robust infrastructure that powers NERO Chain's unique capabilities:

The **AA Platform** serves as a control center for developers, providing a dashboard to configure paymaster settings, monitor quotas, and track usage. Through this platform, developers can define which tokens are accepted for gas payment, set spending limits, and configure other parameters that govern how users interact with their dApps.

For token-based gas payments, the **Price Service** handles the critical function of determining exchange rates between ERC20 tokens and gas costs. This ensures users pay a fair amount when using tokens instead of the native NERO currency for gas.

**Bundlers** are specialized services that collect UserOperations from multiple users and bundle them into standard transactions. By batching operations together, bundlers increase efficiency and reduce costs. These services listen for UserOperations and submit them to the EntryPoint contract.

The **Paymaster** contract is responsible for the actual gas fee abstraction. It verifies whether a transaction should be sponsored and handles the accounting for token-based payments. The Paymaster interacts directly with the EntryPoint to ensure gas costs are covered appropriately.

The **EntryPoint** contract (deployed at `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789`) serves as the central hub for all UserOperations. This standardized contract processes bundled operations and interacts with both Contract Accounts and Paymasters to execute transactions.

Each user's **Contract Account** is a smart contract wallet deployed using the account factory. These accounts execute the actual transaction logic and can implement additional features like multi-signature requirements, spending limits, or account recovery mechanisms.

For advanced use cases, the optional **Aggregator** component handles signature aggregation, enabling more efficient processing of multi-signature operations.

## Transaction Flow

### Connection Phase
The journey begins when a user connects to a dApp. This initial connection establishes the communication channel between the user's browser and the blockchain. During this phase, the user authenticates using their preferred method (MetaMask, social login, password, etc.), and the dApp identifies their AA wallet address, which may be a counterfactual address if the wallet hasn't been deployed yet.

### UserOperation Construction Phase
Once connected, the transaction preparation process begins. When a user initiates an action, such as swapping tokens or minting an NFT, the dApp constructs a UserOperation either directly or through the Developer SDK. Unlike traditional transactions, UserOperations include additional fields necessary for account abstraction.

If gas abstraction is desired, the Developer SDK communicates with the Paymaster API to determine payment options. For token-based payments, the Price Service calculates the exact token amount needed based on current exchange rates and expected gas consumption. The Paymaster API then returns the paymasterAndData field, which includes all necessary information for gas handling.

This modular approach allows developers to offer flexible payment options without modifying their core application logic. Users can choose to pay with tokens they already have rather than acquiring the native token specifically for gas fees.

### Transaction Submission Phase
With the UserOperation constructed and signed, the submission process begins. The dApp sends the complete UserOperation to the Wallet SDK, which handles the interaction with the user to obtain their signature. This might involve a popup in MetaMask or an in-app signature request, depending on the authentication method.

After signing, the AA Wallet forwards the UserOperation to the Bundlers. These specialized services collect operations from multiple users to optimize gas usage and increase efficiency. By batching operations together, Bundlers can reduce the per-operation cost significantly.

### Execution Phase
The final stage occurs when the Bundler has collected enough operations or reached a time threshold. The Bundler creates a transaction calling the EntryPoint contract with a batch of UserOperations. The EntryPoint then processes each operation sequentially.

For each operation, the EntryPoint verifies the signature, checks that gas requirements are met (either through the user's wallet balance or via a Paymaster), and then calls the user's Contract Account to execute the actual transaction logic. If a Paymaster is involved, it handles the gas payment according to the configured strategy.

This multi-step process happens transparently to the end user, who simply sees their transaction being processed and eventually confirmed, similar to a traditional transaction but with enhanced flexibility and potentially lower costs.

### Administrative Components
Behind the scenes, developers maintain control over their gas sponsorship policies through the AA Platform. Here, they can configure payment strategies, set daily quotas, and monitor usage patterns. This administrative layer ensures that gas sponsorship remains economically viable for developers while providing a superior user experience.

![Aa-platform policies](https://docs.nerochain.io/assets/aaPlatform/aa-platform-policies.png)

*Figure 3: AA-platform policies configuration dashboard.*

NERO operators also have access to platform-level settings, allowing them to manage the overall system health and ensure fair resource allocation.

## Paymaster Payment Types and User Experience

The Paymaster system is one of NERO Chain's most innovative features, enabling flexible gas payment mechanisms that dramatically improve user experience. Let's explore the different payment types and their implications:

### Type 0: Developer-Sponsored Gas (Free)

With Type 0 payments, developers fully cover the gas costs for their users. This creates a frictionless experience similar to Web2 applications, where users don't need to think about transaction fees.

This model is ideal for user onboarding, where requiring new users to acquire a specific token creates unnecessary friction. By sponsoring gas for initial interactions, developers can create a smooth path for users to experience their application's value before requiring token acquisition.

Promotional campaigns also benefit from sponsored gas, allowing temporary removal of transaction costs to drive engagement. Gaming applications and metaverse experiences particularly benefit from hiding blockchain complexity, letting users focus on gameplay rather than gas management.

To implement Type 0 payments, developers maintain a balance in their AA Platform account, setting daily or per-user limits to control costs. The platform provides analytics to help optimize sponsorship strategies based on user behavior and conversion metrics.

### Type 1: Prepay with ERC20 Tokens

The Type 1 payment model allows users to pay gas fees using ERC20 tokens they already own, rather than requiring them to hold NERO tokens. This removes a significant adoption barrier, especially for applications with their own token ecosystems.

When using Type 1, the full estimated gas amount (converted to the equivalent value in the selected token) is collected from the user before transaction execution. After the transaction completes, any excess tokens are automatically refunded to the user.

This approach provides certainty for both users and developers: users know the maximum they might spend, and developers know the payment is secured before execution. The model works particularly well for high-value operations where the gas cost is a small fraction of the total transaction value.

Implementation requires users to approve the Paymaster contract to spend their tokens, which is typically handled through the Wallet SDK with appropriate UI guidance.

### Type 2: Postpay with ERC20 Tokens

The Type 2 payment model also uses ERC20 tokens for gas but collects payment after transaction execution. This optimizes the user experience by only charging for the exact gas consumed rather than requiring an upfront estimate with a later refund.

Users appreciate paying exactly what's needed, especially for transactions where gas costs might vary significantly based on execution paths in the contract. However, this model introduces a risk of payment failure if the user's token balance or approval is insufficient after the transaction executes.

This model works best when integrated with applications where users are likely to maintain token balances for other purposes, minimizing the risk of payment failure.

## Building Advanced Applications

The NERO Chain architecture enables developers to create applications with capabilities that weren't previously possible or practical. Here are some examples of what you can build:

**Token-Centric Ecosystems**: By allowing users to pay gas with your application's token, you can create a closed ecosystem where users never need to leave your token economy. This increases the utility and demand for your token while simplifying the user experience.

**Frictionless Onboarding**: Implement a gradual onboarding process where new users enjoy sponsored transactions initially, then transition to token payments once they're engaged with your platform. This removes the "crypto complexity" that often deters mainstream users.

**Bundled Transactions**: Enable users to perform multiple actions in a single operation, such as approving and swapping tokens or minting multiple NFTs. This reduces costs and improves the user experience by minimizing the number of confirmations needed.

**Enhanced Security Features**: Build applications with advanced security features like multi-signature requirements, spending limits, or time locks. The smart contract wallet architecture makes these features much easier to implement than with traditional EOAs.

**Social Recovery Systems**: Implement account recovery mechanisms that don't depend on private key backup, such as social recovery through trusted friends or service providers. This addresses one of the biggest user experience challenges in crypto - fear of losing access to funds.

**Subscription Models**: Create subscription-based services where users authorize recurring payments, similar to traditional subscription apps. The Paymaster can handle gas costs for these pre-approved transactions.

By understanding and leveraging the full capabilities of NERO Chain's architecture, you can build applications that offer the security and ownership benefits of blockchain without the traditional UX limitations.

In the following sections, we'll provide detailed guides on implementing each of these components in your application.


Welcome to the NERO Chain Docs

# Welcome to the NERO Chain Docs
## Builder Journeys
## Quick Start Guides
## Popular Development Guides
## Account Abstraction Technologies
## Essential Tools
## Technical Resources
## About NERO Chain

Welcome to the definitive reference for all things NERO Chain technology, ecosystem, and development. Whether you're a developer building applications, an operator running nodes, a researcher exploring the architecture, or just getting started with blockchain, this documentation will help you understand and leverage NERO Chain's unique features.

## Builder Journeys

<svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M12.316 3.051a1 1 0 01.633 1.265l-4 12a1 1 0 11-1.898-.632l4-12a1 1 0 011.265-.633zM5.707 6.293a1 1 0 010 1.414L3.414 10l2.293 2.293a1 1 0 11-1.414 1.414l-3-3a1 1 0 010-1.414l3-3a1 1 0 011.414 0zm8.586 0a1 1 0 011.414 0l3 3a1 1 0 010 1.414l-3 3a1 1 0 11-1.414-1.414L16.586 10l-2.293-2.293a1 1 0 010-1.414z" clipRule="evenodd" />
      </svg>
      dApp Developers

Build dApps with unique NERO features.

      <svg width="115" height="28" viewBox="0 0 115 28" fill="none" xmlns="http://www.w3.org/2000/svg">
        <rect x="0.5" y="0.5" width="114" height="27" rx="3.5" fill="white" stroke="#000000" className="dark:stroke-white" />
        <text x="12" y="18" fontFamily="system-ui, sans-serif" fontSize="12" fill="#000000" className="dark:fill-white">Start building →</text>
      </svg>

  <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M10 18a8 8 0 100-16 8 8 0 000 16zM4.332 8.027a6.012 6.012 0 011.912-2.706C6.512 5.73 6.974 6 7.5 6A1.5 1.5 0 019 7.5V8a2 2 0 004 0 2 2 0 011.523-1.943A5.977 5.977 0 0116 10c0 .34-.028.675-.083 1H15a2 2 0 00-2 2v2.197A5.973 5.973 0 0110 16v-2a2 2 0 00-2-2 2 2 0 01-2-2 2 2 0 00-1.668-1.973z" clipRule="evenodd" />
      </svg>
      Chain & Node Operators

Deploy and maintain NERO Chain networks and validator nodes.

      <svg width="135" height="28" viewBox="0 0 135 28" fill="none" xmlns="http://www.w3.org/2000/svg">
        <rect x="0.5" y="0.5" width="134" height="27" rx="3.5" fill="white" stroke="#000000" className="dark:stroke-white" />
        <text x="10" y="18" fontFamily="system-ui, sans-serif" fontSize="12" fill="#000000" className="dark:fill-white">Run infrastructure →</text>
      </svg>

  <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M8 4a4 4 0 100 8 4 4 0 000-8zM2 8a6 6 0 1110.89 3.476l4.817 4.817a1 1 0 01-1.414 1.414l-4.816-4.816A6 6 0 012 8z" clipRule="evenodd" />
      </svg>
      Researchers & Developers

Explore technical architecture, innovations, and protocol details.

      <svg width="135" height="28" viewBox="0 0 135 28" fill="none" xmlns="http://www.w3.org/2000/svg">
        <rect x="0.5" y="0.5" width="134" height="27" rx="3.5" fill="white" stroke="#000000" className="dark:stroke-white" />
        <text x="10" y="18" fontFamily="system-ui, sans-serif" fontSize="12" fill="#000000" className="dark:fill-white">Learn technology →</text>
      </svg>

## Quick Start Guides

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M6.267 3.455a3.066 3.066 0 001.745-.723 3.066 3.066 0 013.976 0 3.066 3.066 0 001.745.723 3.066 3.066 0 012.812 2.812c.051.643.304 1.254.723 1.745a3.066 3.066 0 010 3.976 3.066 3.066 0 00-.723 1.745 3.066 3.066 0 01-2.812 2.812 3.066 3.066 0 00-1.745.723 3.066 3.066 0 01-3.976 0 3.066 3.066 0 00-1.745-.723 3.066 3.066 0 01-2.812-2.812 3.066 3.066 0 00-.723-1.745 3.066 3.066 0 010-3.976 3.066 3.066 0 00.723-1.745 3.066 3.066 0 012.812-2.812zm7.44 5.252a1 1 0 00-1.414-1.414L9 10.586 7.707 9.293a1 1 0 00-1.414 1.414l2 2a1 1 0 001.414 0l4-4z" clipRule="evenodd" />
      </svg>
      Developer Tools

Understand NERO Chain's unique features.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path d="M9 4.804A7.968 7.968 0 005.5 4c-1.255 0-2.443.29-3.5.804v10A7.969 7.969 0 015.5 14c1.669 0 3.218.51 4.5 1.385A7.962 7.962 0 0114.5 14c1.255 0 2.443.29 3.5.804v-10A7.968 7.968 0 0014.5 4c-1.255 0-2.443.29-3.5.804V12a1 1 0 11-2 0V4.804z" />
      </svg>
      Developer Cookbook

Practical recipes for building on NERO Chain.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M18 10a8 8 0 11-16 0 8 8 0 0116 0zm-8-3a1 1 0 00-.867.5 1 1 0 11-1.731-1A3 3 0 0113 8a3.001 3.001 0 01-2 2.83V11a1 1 0 11-2 0v-1a1 1 0 011-1 1 1 0 100-2zm0 8a1 1 0 100-2 1 1 0 000 2z" clipRule="evenodd" />
      </svg>
      FAQ

Common challenges and their solutions.

## Popular Development Guides

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-blue-600" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M12.586 4.586a2 2 0 112.828 2.828l-3 3a2 2 0 01-2.828 0 1 1 0 00-1.414 1.414 4 4 0 005.656 0l3-3a4 4 0 00-5.656-5.656l-1.5 1.5a1 1 0 101.414 1.414l1.5-1.5zm-5 5a2 2 0 012.828 0 1 1 0 101.414-1.414 4 4 0 00-5.656 0l-3 3a4 4 0 105.656 5.656l1.5-1.5a1 1 0 10-1.414-1.414l-1.5 1.5a2 2 0 11-2.828-2.828l3-3z" clipRule="evenodd" />
      </svg>
      Deploy First Contract

Deploy a smart contract on NERO Chain.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-green-600" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M4 2a1 1 0 011 1v2.101a7.002 7.002 0 0111.601 2.566 1 1 0 11-1.885.666A5.002 5.002 0 005.999 7H9a1 1 0 010 2H4a1 1 0 01-1-1V3a1 1 0 011-1zm.008 9.057a1 1 0 011.276.61A5.002 5.002 0 0014.001 13H11a1 1 0 110-2h5a1 1 0 011 1v5a1 1 0 11-2 0v-2.101a7.002 7.002 0 01-11.601-2.566 1 1 0 01.61-1.276z" clipRule="evenodd" />
      </svg>
      Build Your First dApp

Create a dApp with NEROWallet.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-purple-600" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M5 2a2 2 0 00-2 2v14l3.5-2 3.5 2 3.5-2 3.5 2V4a2 2 0 00-2-2H5zm4.707 3.707a1 1 0 00-1.414-1.414l-3 3a1 1 0 000 1.414l3 3a1 1 0 001.414-1.414L8.414 9l1.293-1.293z" clipRule="evenodd" />
      </svg>
      Low Level Building

Low-Level Building from scratch.

## Account Abstraction Technologies

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-yellow-500" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M6.672 1.911a1 1 0 10-1.932.518l.259.966a1 1 0 001.932-.518l-.26-.966zM2.429 4.74a1 1 0 10-.517 1.932l.966.259a1 1 0 00.517-1.932l-.966-.26zm8.814-.569a1 1 0 00-1.415-1.414l-.707.707a1 1 0 101.415 1.415l.707-.708zm-7.071 7.072l.707-.707A1 1 0 003.465 9.12l-.708.707a1 1 0 001.415 1.415zm3.2-5.171a1 1 0 00-1.3 1.3l4 10a1 1 0 001.823.075l1.38-2.759 3.018 3.02a1 1 0 001.414-1.415l-3.019-3.02 2.76-1.379a1 1 0 00-.076-1.822l-10-4z" clipRule="evenodd" />
      </svg>
      UserOp SDK

Create and send UserOperations with our JavaScript SDK.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-blue-500" viewBox="0 0 20 20" fill="currentColor">
        <path d="M8.433 7.418c.155-.103.346-.196.567-.267v1.698a2.305 2.305 0 01-.567-.267C8.07 8.34 8 8.114 8 8c0-.114.07-.34.433-.582zM11 12.849v-1.698c.22.071.412.164.567.267.364.243.433.468.433.582 0 .114-.07.34-.433.582a2.305 2.305 0 01-.567.267z" />
        <path fillRule="evenodd" d="M10 18a8 8 0 100-16 8 8 0 000 16zm1-13a1 1 0 10-2 0v.092a4.535 4.535 0 00-1.676.662C6.602 6.234 6 7.009 6 8c0 .99.602 1.765 1.324 2.246.48.32 1.054.545 1.676.662v1.941c-.391-.127-.68-.317-.843-.504a1 1 0 10-1.51 1.31c.562.649 1.413 1.076 2.353 1.253V15a1 1 0 102 0v-.092a4.535 4.535 0 001.676-.662C13.398 13.766 14 12.991 14 12c0-.99-.602-1.765-1.324-2.246A4.535 4.535 0 0011 9.092V7.151c.391.127.68.317.843.504a1 1 0 101.511-1.31c-.563-.649-1.413-1.076-2.354-1.253V5z" clipRule="evenodd" />
      </svg>
      AA Wallet Integration

Implement smart contract wallets in your applications.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-red-500" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M4 4a2 2 0 00-2 2v4a2 2 0 002 2V6h10a2 2 0 00-2-2H4zm2 6a2 2 0 012-2h8a2 2 0 012 2v4a2 2 0 01-2 2H8a2 2 0 01-2-2v-4zm6 4a2 2 0 100-4 2 2 0 000 4z" clipRule="evenodd" />
      </svg>
      AA Platform

Manage gas sponsorship policies and payment strategies.

## Essential Tools

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M5 2a1 1 0 011 1v1h1a1 1 0 010 2H6v1a1 1 0 01-2 0V6H3a1 1 0 010-2h1V3a1 1 0 011-1zm0 10a1 1 0 011 1v1h1a1 1 0 110 2H6v1a1 1 0 11-2 0v-1H3a1 1 0 110-2h1v-1a1 1 0 011-1zM12 2a1 1 0 01.967.744L14.146 7.2 17.5 9.134a1 1 0 010 1.732l-3.354 1.935-1.18 4.455a1 1 0 01-1.933 0L9.854 12.8 6.5 10.866a1 1 0 010-1.732l3.354-1.935 1.18-4.455A1 1 0 0112 2z" clipRule="evenodd" />
      </svg>
      NERO Faucet

Get testnet tokens to start building.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path d="M11 17a1 1 0 001.447.894l4-2A1 1 0 0017 15V9.236a1 1 0 00-1.447-.894l-4 2a1 1 0 00-.553.894V17zM15.211 6.276a1 1 0 000-1.788l-4.764-2.382a1 1 0 00-.894 0L4.789 4.488a1 1 0 000 1.788l4.764 2.382a1 1 0 00.894 0l4.764-2.382zM4.447 8.342A1 1 0 003 9.236V15a1 1 0 00.553.894l4 2A1 1 0 009 17v-5.764a1 1 0 00-.553-.894l-4-2z" />
      </svg>
      NERO Explorer

Explore blocks, transactions, and accounts.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M10 18a8 8 0 100-16 8 8 0 000 16zm1-13a1 1 0 10-2 0v.092a4.535 4.535 0 00-1.676.662C6.602 6.234 6 7.009 6 8c0 .99.602 1.765 1.324 2.246.48.32 1.054.545 1.676.662v1.941c-.391-.127-.68-.317-.843-.504a1 1 0 10-1.51 1.31c.562.649 1.413 1.076 2.353 1.253V15a1 1 0 102 0v-.092a4.535 4.535 0 001.676-.662C13.398 13.766 14 12.991 14 12c0-.99-.602-1.765-1.324-2.246A4.535 4.535 0 0011 9.092V7.151c.391.127.68.317.843.504a1 1 0 101.511-1.31c-.563-.649-1.413-1.076-2.354-1.253V5z" clipRule="evenodd" />
      </svg>
      Access Paymaster

Manage gas fees for your users.

## Technical Resources

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M3 4a1 1 0 011-1h12a1 1 0 110 2H4a1 1 0 01-1-1zm0 4a1 1 0 011-1h12a1 1 0 110 2H4a1 1 0 01-1-1zm0 4a1 1 0 011-1h12a1 1 0 110 2H4a1 1 0 01-1-1zm0 4a1 1 0 011-1h12a1 1 0 110 2H4a1 1 0 01-1-1z" clipRule="evenodd" />
      </svg>
      Network Info

All Network informations.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path d="M9 4.804A7.968 7.968 0 005.5 4c-1.255 0-2.443.29-3.5.804v10A7.969 7.969 0 015.5 14c1.669 0 3.218.51 4.5 1.385A7.962 7.962 0 0114.5 14c1.255 0 2.443.29 3.5.804v-10A7.968 7.968 0 0014.5 4c-1.255 0-2.443.29-3.5.804V12a1 1 0 11-2 0V4.804z" />
      </svg>
      GitHub Repos

Check our public codes.

    <svg xmlns="http://www.w3.org/2000/svg" style={{height: '1.25rem', width: '1.25rem', marginRight: '0.5rem'}} className="text-nero-brand" viewBox="0 0 20 20" fill="currentColor">
        <path fillRule="evenodd" d="M18 10a8 8 0 11-16 0 8 8 0 0116 0zm-8-3a1 1 0 00-.867.5 1 1 0 11-1.731-1A3 3 0 0113 8a3.001 3.001 0 01-2 2.83V11a1 1 0 11-2 0v-1a1 1 0 011-1 1 1 0 100-2zm0 8a1 1 0 100-2 1 1 0 000 2z" clipRule="evenodd" />
      </svg>
      Support

Contact Us.

## About NERO Chain

Built as a modular blockchain, NERO Chain stresses providing value to applications over infrastructure-level value capture. NERO Chain changes traditional blockchain economics by letting dApps gather and share transaction value, therefore ensuring that the success of an application benefits its developers and users instead of just the underlying network. With its complete EVM compatibility and high-performance settling layer, Nero offers amazing scalability and flexibility, including native account abstraction, paymaster-driven gas sponsorship, and current technologies like Blockspace 2.0 which provide developers with a flawless experience.


Command-line Options

Geth is primarily controlled using the command line. Geth is started using the geth command. It is stopped by pressing ctrl-c.

You can configure Geth using command-line options (a.k.a. flags). Geth also has sub-commands, which can be used to invoke functionality such as the console or blockchain import/export.

The command-line help listing is reproduced below for your convenience. The same information can be obtained at any time from your own Geth instance by running:

```
geth --help
```

## Commands

```shell showLineNumbers{1}
NAME:
   geth - the go-ethereum command line interface

USAGE:
   geth [global options] command [command options] [arguments...]

VERSION:
   1.13.1-stable-3f40e65c

COMMANDS:
   account                Manage accounts
   attach                 Start an interactive JavaScript environment (connect to node)
   console                Start an interactive JavaScript environment
   db                     Low level database operations
   dump                   Dump a specific block from storage
   dumpconfig             Export configuration values in a TOML format
   dumpgenesis            Dumps genesis block JSON configuration to stdout
   export                 Export blockchain into file
   export-preimages       Export the preimage database into an RLP stream
   import-preimages       Import the preimage database from an RLP stream
   init                   Bootstrap and initialize a new genesis block
   js                     (DEPRECATED) Execute the specified JavaScript files
   license                Display license information
   removedb               Remove blockchain and state databases
   show-deprecated-flags  Show flags that have been deprecated
   snapshot               A set of commands based on the snapshot
   verkle                 A set of experimental verkle tree management commands
   version                Print version numbers
   version-check          Checks (online) for known Geth security vulnerabilities
   wallet                 Manage Ethereum presale wallets
   help, h                Shows a list of commands or help for one command

GLOBAL OPTIONS:

    --log.rotate                        (default: false)                   ($GETH_LOG_ROTATE)
          Enables log file rotation

   ACCOUNT

    --allow-insecure-unlock             (default: false)                   ($GETH_ALLOW_INSECURE_UNLOCK)
          Allow insecure account unlocking when account-related RPCs are exposed by http

    --keystore value                                                       ($GETH_KEYSTORE)
          Directory for the keystore (default = inside the datadir)

    --lightkdf                          (default: false)                   ($GETH_LIGHTKDF)
          Reduce key-derivation RAM & CPU usage at some expense of KDF strength

    --password value                                                       ($GETH_PASSWORD)
          Password file to use for non-interactive password input

    --pcscdpath value                   (default: "/run/pcscd/pcscd.comm") ($GETH_PCSCDPATH)
          Path to the smartcard daemon (pcscd) socket file

    --signer value                                                         ($GETH_SIGNER)
          External signer (url or path to ipc file)

    --unlock value                                                         ($GETH_UNLOCK)
          Comma separated list of accounts to unlock

    --usb                               (default: false)                   ($GETH_USB)
          Enable monitoring and management of USB hardware wallets

   ALIASED (deprecated)

    --cache.trie.journal value                                             ($GETH_CACHE_TRIE_JOURNAL)
          Disk journal directory for trie cache to survive node restarts

    --cache.trie.rejournal value        (default: 0s)                      ($GETH_CACHE_TRIE_REJOURNAL)
          Time interval to regenerate the trie cache journal

    --nousb                             (default: false)                   ($GETH_NOUSB)
          Disables monitoring for and managing USB hardware wallets (deprecated)

    --txlookuplimit value               (default: 2350000)                 ($GETH_TXLOOKUPLIMIT)
          Number of recent blocks to maintain transactions index for (default = about one
          year, 0 = entire chain) (deprecated, use history.transactions instead)

    --v5disc                            (default: false)                   ($GETH_V5DISC)
          Enables the experimental RLPx V5 (Topic Discovery) mechanism (deprecated, use
          --discv5 instead)

    --whitelist value                                                      ($GETH_WHITELIST)
          Comma separated block number-to-hash mappings to enforce (<number>=<hash>)
          (deprecated in favor of --eth.requiredblocks)

   API AND CONSOLE

    --authrpc.addr value                (default: "localhost")             ($GETH_AUTHRPC_ADDR)
          Listening address for authenticated APIs

    --authrpc.jwtsecret value                                              ($GETH_AUTHRPC_JWTSECRET)
          Path to a JWT secret to use for authenticated RPC endpoints

    --authrpc.port value                (default: 8551)                    ($GETH_AUTHRPC_PORT)
          Listening port for authenticated APIs

    --authrpc.vhosts value              (default: "localhost")             ($GETH_AUTHRPC_VHOSTS)
          Comma separated list of virtual hostnames from which to accept requests (server
          enforced). Accepts '*' wildcard.

    --exec value                                                           ($GETH_EXEC)
          Execute JavaScript statement

    --graphql                           (default: false)                   ($GETH_GRAPHQL)
          Enable GraphQL on the HTTP-RPC server. Note that GraphQL can only be started if
          an HTTP server is started as well.

    --graphql.corsdomain value                                             ($GETH_GRAPHQL_CORSDOMAIN)
          Comma separated list of domains from which to accept cross origin requests
          (browser enforced)

    --graphql.vhosts value              (default: "localhost")             ($GETH_GRAPHQL_VHOSTS)
          Comma separated list of virtual hostnames from which to accept requests (server
          enforced). Accepts '*' wildcard.

    --header value, -H value
          Pass custom headers to the RPC server when using --remotedb or the geth attach
          console. This flag can be given multiple times.

    --http                              (default: false)                   ($GETH_HTTP)
          Enable the HTTP-RPC server

    --http.addr value                   (default: "localhost")             ($GETH_HTTP_ADDR)
          HTTP-RPC server listening interface

    --http.api value                                                       ($GETH_HTTP_API)
          API's offered over the HTTP-RPC interface

    --http.corsdomain value                                                ($GETH_HTTP_CORSDOMAIN)
          Comma separated list of domains from which to accept cross origin requests
          (browser enforced)

    --http.port value                   (default: 8545)                    ($GETH_HTTP_PORT)
          HTTP-RPC server listening port

    --http.rpcprefix value                                                 ($GETH_HTTP_RPCPREFIX)
          HTTP path path prefix on which JSON-RPC is served. Use '/' to serve on all
          paths.

    --http.vhosts value                 (default: "localhost")             ($GETH_HTTP_VHOSTS)
          Comma separated list of virtual hostnames from which to accept requests (server
          enforced). Accepts '*' wildcard.

    --ipcdisable                        (default: false)                   ($GETH_IPCDISABLE)
          Disable the IPC-RPC server

    --ipcpath value                                                        ($GETH_IPCPATH)
          Filename for IPC socket/pipe within the datadir (explicit paths escape it)

    --jspath value                      (default: .)                       ($GETH_JSPATH)
          JavaScript root path for `loadScript`

    --preload value                                                        ($GETH_PRELOAD)
          Comma separated list of JavaScript files to preload into the console

    --rpc.allow-unprotected-txs         (default: false)                   ($GETH_RPC_ALLOW_UNPROTECTED_TXS)
          Allow for unprotected (non EIP155 signed) transactions to be submitted via RPC

    --rpc.batch-request-limit value     (default: 1000)                    ($GETH_RPC_BATCH_REQUEST_LIMIT)
          Maximum number of requests in a batch

    --rpc.batch-response-max-size value (default: 25000000)                ($GETH_RPC_BATCH_RESPONSE_MAX_SIZE)
          Maximum number of bytes returned from a batched call

    --rpc.enabledeprecatedpersonal      (default: false)                   ($GETH_RPC_ENABLEDEPRECATEDPERSONAL)
          Enables the (deprecated) personal namespace

    --rpc.evmtimeout value              (default: 5s)                      ($GETH_RPC_EVMTIMEOUT)
          Sets a timeout used for eth_call (0=infinite)

    --rpc.gascap value                  (default: 50000000)                ($GETH_RPC_GASCAP)
          Sets a cap on gas that can be used in eth_call/estimateGas (0=infinite)

    --rpc.txfeecap value                (default: 1)
          Sets a cap on transaction fee (in ether) that can be sent via the RPC APIs (0 =
          no cap)

    --ws                                (default: false)                   ($GETH_WS)
          Enable the WS-RPC server

    --ws.addr value                     (default: "localhost")             ($GETH_WS_ADDR)
          WS-RPC server listening interface

    --ws.api value                                                         ($GETH_WS_API)
          API's offered over the WS-RPC interface

    --ws.origins value                                                     ($GETH_WS_ORIGINS)
          Origins from which to accept websockets requests

    --ws.port value                     (default: 8546)                    ($GETH_WS_PORT)
          WS-RPC server listening port

    --ws.rpcprefix value                                                   ($GETH_WS_RPCPREFIX)
          HTTP path prefix on which JSON-RPC is served. Use '/' to serve on all paths.

   DEVELOPER CHAIN

    --dev                               (default: false)                   ($GETH_DEV)
          Ephemeral proof-of-authority network with a pre-funded developer account, mining
          enabled

    --dev.gaslimit value                (default: 11500000)                ($GETH_DEV_GASLIMIT)
          Initial block gas limit

    --dev.period value                  (default: 0)                       ($GETH_DEV_PERIOD)
          Block period to use in developer mode (0 = mine only if transaction pending)

   ETHEREUM

    --bloomfilter.size value            (default: 2048)                    ($GETH_BLOOMFILTER_SIZE)
          Megabytes of memory allocated to bloom-filter for pruning

    --config value                                                         ($GETH_CONFIG)
          TOML configuration file

    --datadir value                     (default: /root/.ethereum)         ($GETH_DATADIR)
          Data directory for the databases and keystore

    --datadir.ancient value                                                ($GETH_DATADIR_ANCIENT)
          Root directory for ancient data (default = inside chaindata)

    --datadir.minfreedisk value                                            ($GETH_DATADIR_MINFREEDISK)
          Minimum free disk space in MB, once reached triggers auto shut down (default =
          --cache.gc converted to MB, 0 = disabled)

    --db.engine value                                                      ($GETH_DB_ENGINE)
          Backing database implementation to use ('pebble' or 'leveldb')

    --eth.requiredblocks value                                             ($GETH_ETH_REQUIREDBLOCKS)
          Comma separated block number-to-hash mappings to require for peering
          (<number>=<hash>)

    --exitwhensynced                    (default: false)                   ($GETH_EXITWHENSYNCED)
          Exits after block synchronisation completes

    --goerli                            (default: false)                   ($GETH_GOERLI)
          Görli network: pre-configured proof-of-authority test network

    --holesky                           (default: false)                   ($GETH_HOLESKY)
          Holesky network: pre-configured proof-of-stake test network

    --mainnet                           (default: false)                   ($GETH_MAINNET)
          Ethereum mainnet

    --networkid value                   (default: 1)                       ($GETH_NETWORKID)
          Explicitly set network id (integer)(For testnets: use --goerli, --sepolia,
          --holesky instead)

    --override.cancun value             (default: 0)                       ($GETH_OVERRIDE_CANCUN)
          Manually specify the Cancun fork timestamp, overriding the bundled setting

    --override.verkle value             (default: 0)                       ($GETH_OVERRIDE_VERKLE)
          Manually specify the Verkle fork timestamp, overriding the bundled setting

    --sepolia                           (default: false)                   ($GETH_SEPOLIA)
          Sepolia network: pre-configured proof-of-work test network

    --snapshot                          (default: true)                    ($GETH_SNAPSHOT)
          Enables snapshot-database mode (default = enable)

   GAS PRICE ORACLE

    --gpo.blocks value                  (default: 20)                      ($GETH_GPO_BLOCKS)
          Number of recent blocks to check for gas prices

    --gpo.ignoreprice value             (default: 2)
          Gas price below which gpo will ignore transactions

    --gpo.maxprice value                (default: 500000000000)
          Maximum transaction priority fee (or gasprice before London fork) to be
          recommended by gpo

    --gpo.percentile value              (default: 60)                      ($GETH_GPO_PERCENTILE)
          Suggested gas price is the given percentile of a set of recent transaction gas
          prices

   LIGHT CLIENT

    --light.egress value                (default: 0)                       ($GETH_LIGHT_EGRESS)
          Outgoing bandwidth limit for serving light clients (kilobytes/sec, 0 =
          unlimited)

    --light.ingress value               (default: 0)                       ($GETH_LIGHT_INGRESS)
          Incoming bandwidth limit for serving light clients (kilobytes/sec, 0 =
          unlimited)

    --light.maxpeers value              (default: 100)                     ($GETH_LIGHT_MAXPEERS)
          Maximum number of light clients to serve, or light servers to attach to

    --light.nopruning                   (default: false)                   ($GETH_LIGHT_NOPRUNING)
          Disable ancient light chain data pruning

    --light.nosyncserve                 (default: false)                   ($GETH_LIGHT_NOSYNCSERVE)
          Enables serving light clients before syncing

    --light.serve value                 (default: 0)                       ($GETH_LIGHT_SERVE)
          Maximum percentage of time allowed for serving LES requests (multi-threaded
          processing allows values over 100)

   LOGGING AND DEBUGGING

    --log.backtrace value                                                  ($GETH_LOG_BACKTRACE)
          Request a stack trace at a specific logging statement (e.g. "block.go:271")

    --log.compress                      (default: false)                   ($GETH_LOG_COMPRESS)
          Compress the log files

    --log.debug                         (default: false)                   ($GETH_LOG_DEBUG)
          Prepends log messages with call-site location (file and line number)

    --log.file value                                                       ($GETH_LOG_FILE)
          Write logs to a file

    --log.format value                                                     ($GETH_LOG_FORMAT)
          Log format to use (json|logfmt|terminal)

    --log.maxage value                  (default: 30)                      ($GETH_LOG_MAXAGE)
          Maximum number of days to retain a log file

    --log.maxbackups value              (default: 10)                      ($GETH_LOG_MAXBACKUPS)
          Maximum number of log files to retain

    --log.maxsize value                 (default: 100)                     ($GETH_LOG_MAXSIZE)
          Maximum size in MBs of a single log file

    --log.vmodule value                                                    ($GETH_LOG_VMODULE)
          Per-module verbosity: comma-separated list of <pattern>=<level> (e.g.
          eth/*=5,p2p=4)

    --nocompaction                      (default: false)                   ($GETH_NOCOMPACTION)
          Disables db compaction after import

    --pprof                             (default: false)                   ($GETH_PPROF)
          Enable the pprof HTTP server

    --pprof.addr value                  (default: "127.0.0.1")             ($GETH_PPROF_ADDR)
          pprof HTTP server listening interface

    --pprof.blockprofilerate value      (default: 0)                       ($GETH_PPROF_BLOCKPROFILERATE)
          Turn on block profiling with the given rate

    --pprof.cpuprofile value                                               ($GETH_PPROF_CPUPROFILE)
          Write CPU profile to the given file

    --pprof.memprofilerate value        (default: 524288)                  ($GETH_PPROF_MEMPROFILERATE)
          Turn on memory profiling with the given rate

    --pprof.port value                  (default: 6060)                    ($GETH_PPROF_PORT)
          pprof HTTP server listening port

    --remotedb value                                                       ($GETH_REMOTEDB)
          URL for remote database

    --trace value                                                          ($GETH_TRACE)
          Write execution trace to the given file

    --verbosity value                   (default: 3)                       ($GETH_VERBOSITY)
          Logging verbosity: 0=silent, 1=error, 2=warn, 3=info, 4=debug, 5=detail

   METRICS AND STATS

    --ethstats value                                                       ($GETH_ETHSTATS)
          Reporting URL of a ethstats service (nodename:secret@host:port)

    --metrics                           (default: false)                   ($GETH_METRICS)
          Enable metrics collection and reporting

    --metrics.addr value                                                   ($GETH_METRICS_ADDR)
          Enable stand-alone metrics HTTP server listening interface.

    --metrics.expensive                 (default: false)                   ($GETH_METRICS_EXPENSIVE)
          Enable expensive metrics collection and reporting

    --metrics.influxdb                  (default: false)                   ($GETH_METRICS_INFLUXDB)
          Enable metrics export/push to an external InfluxDB database

    --metrics.influxdb.bucket value     (default: "geth")                  ($GETH_METRICS_INFLUXDB_BUCKET)
          InfluxDB bucket name to push reported metrics to (v2 only)

    --metrics.influxdb.database value   (default: "geth")                  ($GETH_METRICS_INFLUXDB_DATABASE)
          InfluxDB database name to push reported metrics to

    --metrics.influxdb.endpoint value   (default: "http://localhost:8086") ($GETH_METRICS_INFLUXDB_ENDPOINT)
          InfluxDB API endpoint to report metrics to

    --metrics.influxdb.organization value (default: "geth")                  ($GETH_METRICS_INFLUXDB_ORGANIZATION)
          InfluxDB organization name (v2 only)

    --metrics.influxdb.password value   (default: "test")                  ($GETH_METRICS_INFLUXDB_PASSWORD)
          Password to authorize access to the database

    --metrics.influxdb.tags value       (default: "host=localhost")        ($GETH_METRICS_INFLUXDB_TAGS)
          Comma-separated InfluxDB tags (key/values) attached to all measurements

    --metrics.influxdb.token value      (default: "test")                  ($GETH_METRICS_INFLUXDB_TOKEN)
          Token to authorize access to the database (v2 only)

    --metrics.influxdb.username value   (default: "test")                  ($GETH_METRICS_INFLUXDB_USERNAME)
          Username to authorize access to the database

    --metrics.influxdbv2                (default: false)                   ($GETH_METRICS_INFLUXDBV2)
          Enable metrics export/push to an external InfluxDB v2 database

    --metrics.port value                (default: 6060)                    ($GETH_METRICS_PORT)
          Metrics HTTP server listening port.
          Please note that --metrics.addr must be set
          to start the server.

   MINER

    --mine                              (default: false)                   ($GETH_MINE)
          Enable mining

    --miner.etherbase value                                                ($GETH_MINER_ETHERBASE)
          0x prefixed public address for block mining rewards

    --miner.extradata value                                                ($GETH_MINER_EXTRADATA)
          Block extra data set by the miner (default = client version)

    --miner.gaslimit value              (default: 30000000)                ($GETH_MINER_GASLIMIT)
          Target gas ceiling for mined blocks

    --miner.gasprice value              (default: 0)                       ($GETH_MINER_GASPRICE)
          Minimum gas price for mining a transaction

    --miner.newpayload-timeout value    (default: 2s)                      ($GETH_MINER_NEWPAYLOAD_TIMEOUT)
          Specify the maximum time allowance for creating a new payload

    --miner.recommit value              (default: 2s)                      ($GETH_MINER_RECOMMIT)
          Time interval to recreate the block being mined

   MISC

    --help, -h                          (default: false)
          show help

    --synctarget value                                                     ($GETH_SYNCTARGET)
          File for containing the hex-encoded block-rlp as sync target(dev feature)

    --version, -v                       (default: false)
          print the version

   NETWORKING

    --bootnodes value                                                      ($GETH_BOOTNODES)
          Comma separated enode URLs for P2P discovery bootstrap

    --discovery.dns value                                                  ($GETH_DISCOVERY_DNS)
          Sets DNS discovery entry points (use "" to disable DNS)

    --discovery.port value              (default: 30303)                   ($GETH_DISCOVERY_PORT)
          Use a custom UDP port for P2P discovery

    --discovery.v4, --discv4            (default: true)                    ($GETH_DISCOVERY_V4)
          Enables the V4 discovery mechanism

    --discovery.v5, --discv5            (default: false)                   ($GETH_DISCOVERY_V5)
          Enables the experimental RLPx V5 (Topic Discovery) mechanism

    --identity value                                                       ($GETH_IDENTITY)
          Custom node name

    --maxpeers value                    (default: 50)                      ($GETH_MAXPEERS)
          Maximum number of network peers (network disabled if set to 0)

    --maxpendpeers value                (default: 0)                       ($GETH_MAXPENDPEERS)
          Maximum number of pending connection attempts (defaults used if set to 0)

    --nat value                         (default: "any")                   ($GETH_NAT)
          NAT port mapping mechanism (any|none|upnp|pmp|pmp:<IP>|extip:<IP>)

    --netrestrict value                                                    ($GETH_NETRESTRICT)
          Restricts network communication to the given IP networks (CIDR masks)

    --nodekey value                                                        ($GETH_NODEKEY)
          P2P node key file

    --nodekeyhex value                                                     ($GETH_NODEKEYHEX)
          P2P node key as hex (for testing)

    --nodiscover                        (default: false)                   ($GETH_NODISCOVER)
          Disables the peer discovery mechanism (manual peer addition)

    --port value                        (default: 30303)                   ($GETH_PORT)
          Network listening port

   PERFORMANCE TUNING

    --cache value                       (default: 1024)                    ($GETH_CACHE)
          Megabytes of memory allocated to internal caching (default = 4096 mainnet full
          node, 128 light mode)

    --cache.blocklogs value             (default: 32)                      ($GETH_CACHE_BLOCKLOGS)
          Size (in number of blocks) of the log cache for filtering

    --cache.database value              (default: 50)                      ($GETH_CACHE_DATABASE)
          Percentage of cache memory allowance to use for database io

    --cache.gc value                    (default: 25)                      ($GETH_CACHE_GC)
          Percentage of cache memory allowance to use for trie pruning (default = 25% full
          mode, 0% archive mode)

    --cache.noprefetch                  (default: false)                   ($GETH_CACHE_NOPREFETCH)
          Disable heuristic state prefetch during block import (less CPU and disk IO, more
          time waiting for data)

    --cache.preimages                   (default: false)                   ($GETH_CACHE_PREIMAGES)
          Enable recording the SHA3/keccak preimages of trie keys

    --cache.snapshot value              (default: 10)                      ($GETH_CACHE_SNAPSHOT)
          Percentage of cache memory allowance to use for snapshot caching (default = 10%
          full mode, 20% archive mode)

    --cache.trie value                  (default: 15)                      ($GETH_CACHE_TRIE)
          Percentage of cache memory allowance to use for trie caching (default = 15% full
          mode, 30% archive mode)

    --crypto.kzg value                  (default: "gokzg")                 ($GETH_CRYPTO_KZG)
          KZG library implementation to use; gokzg (recommended) or ckzg

    --fdlimit value                     (default: 0)                       ($GETH_FDLIMIT)
          Raise the open file descriptor resource limit (default = system fd limit)

   STATE HISTORY MANAGEMENT

    --gcmode value                      (default: "full")                  ($GETH_GCMODE)
          Blockchain garbage collection mode, only relevant in state.scheme=hash ("full",
          "archive")

    --history.state value               (default: 90000)                   ($GETH_HISTORY_STATE)
          Number of recent blocks to retain state history for (default = 90,000 blocks, 0
          = entire chain)

    --history.transactions value        (default: 2350000)                 ($GETH_HISTORY_TRANSACTIONS)
          Number of recent blocks to maintain transactions index for (default = about one
          year, 0 = entire chain)

    --state.scheme value                (default: "hash")                  ($GETH_STATE_SCHEME)
          Scheme to use for storing ethereum state ('hash' or 'path')

    --syncmode value                    (default: snap)                    ($GETH_SYNCMODE)
          Blockchain sync mode ("snap", "full" or "light")

   TRANSACTION POOL (BLOB)

    --blobpool.datacap value            (default: 10737418240)             ($GETH_BLOBPOOL_DATACAP)
          Disk space to allocate for pending blob transactions (soft limit)

    --blobpool.datadir value            (default: "blobpool")              ($GETH_BLOBPOOL_DATADIR)
          Data directory to store blob transactions in

    --blobpool.pricebump value          (default: 100)                     ($GETH_BLOBPOOL_PRICEBUMP)
          Price bump percentage to replace an already existing blob transaction

   TRANSACTION POOL (EVM)

    --txpool.accountqueue value         (default: 64)                      ($GETH_TXPOOL_ACCOUNTQUEUE)
          Maximum number of non-executable transaction slots permitted per account

    --txpool.accountslots value         (default: 16)                      ($GETH_TXPOOL_ACCOUNTSLOTS)
          Minimum number of executable transaction slots guaranteed per account

    --txpool.globalqueue value          (default: 1024)                    ($GETH_TXPOOL_GLOBALQUEUE)
          Maximum number of non-executable transaction slots for all accounts

    --txpool.globalslots value          (default: 5120)                    ($GETH_TXPOOL_GLOBALSLOTS)
          Maximum number of executable transaction slots for all accounts

    --txpool.journal value              (default: "transactions.rlp")      ($GETH_TXPOOL_JOURNAL)
          Disk journal for local transaction to survive node restarts

    --txpool.lifetime value             (default: 3h0m0s)                  ($GETH_TXPOOL_LIFETIME)
          Maximum amount of time non-executable transaction are queued

    --txpool.locals value                                                  ($GETH_TXPOOL_LOCALS)
          Comma separated accounts to treat as locals (no flush, priority inclusion)

    --txpool.nolocals                   (default: false)                   ($GETH_TXPOOL_NOLOCALS)
          Disables price exemptions for locally submitted transactions

    --txpool.pricebump value            (default: 10)                      ($GETH_TXPOOL_PRICEBUMP)
          Price bump percentage to replace an already existing transaction

    --txpool.pricelimit value           (default: 1)                       ($GETH_TXPOOL_PRICELIMIT)
          Minimum gas price tip to enforce for acceptance into the pool

    --txpool.rejournal value            (default: 1h0m0s)                  ($GETH_TXPOOL_REJOURNAL)
          Time interval to regenerate the local transaction journal

   VIRTUAL MACHINE

    --vmdebug                           (default: false)                   ($GETH_VMDEBUG)
          Record information useful for VM and contract debugging

COPYRIGHT:
   Copyright 2013-2023 The go-ethereum Authors

```


Compile, Run and Deploy

# Compile, Run and Deploy
## Download
## Install Golang
## Compile
## Run
## Deployment
### Hardware
### Chain Node
### Start Bash
### systemd config

This guide walks you through compiling and running NERO.

## Download

Download the NERO source code using the following git command:

```
git clone https://github.com/nerochain/Nero.git
```

## Install Golang

Before compiling NERO, make sure you have Golang installed on your system. Refer to the official Golang website ([https://go.dev/dl/](https://go.dev/dl/)) for download and installation instructions.

## Compile

1. Navigate to the directory where you cloned the NERO source code using:

   ```
   cd /path/to/Nero
   ```

2. Compile NERO by running the following command:

   ```
   make geth
   ```

   This will create a compiled binary in the `build/bin` folder.

## Run

1. Get a list of available options and their descriptions by running:

   ```
   ./build/bin/geth --help
   ```

2. Refer to the [Command-line Options documentation](./commandLineOptions.mdx) for specific usage details.

**Custom Option:**

NERO offers a custom option named `--traceaction`:

```
--traceaction value     (default: 0)
    Trace internal tx call/create/suicide action, 0=no trace, 1=trace only native token > 0, 2=trace all
```

This option allows you to enable or disable custom JSON-RPC methods for tracing internal transactions.

## Deployment

Introduce systemd management configs.

### Hardware

#### Minimum

```
8core
16g
ssd iops>5k
```

#### Recommended

```
16core
32g
ssd iops>5k
```

#### Network & Port

```
External IP Address
Port TCP/UDP 30303
```

### Chain Node

- config.toml

```
[Eth]
SyncMode = "snap"
TrieTimeout = 1200000000000
StateScheme = "hash"

[Eth.Miner]
GasCeil = 40000000
Recommit = 3000000000
Noverify = false

[Eth.TxPool]
NoLocals = true
Journal = "transactions.rlp"
Rejournal = 600000000000
PriceLimit = 1000000000
PriceBump = 10
AccountSlots = 64
GlobalSlots = 10240
AccountQueue = 32
GlobalQueue = 1024
Lifetime = 1800000000000

[Node]
DataDir = "/data/nerochain/data"
DBEngine = "leveldb"
IPCPath = "geth.ipc"
HTTPHost = "0.0.0.0"
HTTPPort = 8545
HTTPCors = ["*"]
HTTPVirtualHosts = ["*"]
HTTPModules = ['eth', 'net', 'web3', 'turbo', 'engine']

WSHost = "0.0.0.0"
WSPort = 8546
WSModules = ['eth', 'net', 'web3', 'turbo', 'engine']

AuthPort = 8552

GraphQLVirtualHosts = ["localhost"]

[Node.P2P]
MaxPeers = 50
ListenAddr = ":30306"
EnableMsgEvents = false

[Node.HTTPTimeouts]
ReadTimeout = 30000000000
WriteTimeout = 30000000000
IdleTimeout = 120000000000
```

use snap sync in the config, if full needed - change this line

```
SyncMode = "snap"
```

to

```
SyncMode = "full"
```

### Start Bash

> To show full detail help info of all flags, type `geth help` or `geth -h`

- run.sh

```
#!/usr/bin/env bash
/data/nero/chain/geth-linux-amd64 \
--config /data/nero/chain/config.toml  \
--log.file /data/nero/chain/logs/chain.log \
--log.rotate=true \
--traceaction 2 \
--verbosity 3
```

if you need to use it as archive node, add:

```
--syncmode full \
--gcmode archive \
```

so:

```
#!/usr/bin/env bash
/data/nero/chain/geth-linux-amd64 \
--config /data/nero/chain/config.toml  \
--log.file /data/nero/chain/logs/chain.log \
--log.rotate=true \
--traceaction 2 \
--syncmode full \
--gcmode archive \
--verbosity 3
```

If no network flags were provided, the node will connect the NERO mainnet by default. If you want to connect to NERO testnet, add:

```
--testnet
```

### systemd config

```
[Unit]
Description=NERO chain service

[Service]
Type=simple
ExecStart=/bin/sh /data/nero/chain/run.sh
WorkingDirectory=/data/nero/chain
TimeoutSec=600
Restart=on-failure
RestartSec=5s

LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
```