---
name: chainstack
description: Use when deploying and managing blockchain RPC nodes, accessing
  blockchain data via APIs, configuring node security and access rules, managing
  projects and billing, or integrating blockchain infrastructure into
  applications. Agents should reach for this skill when users need to set up
  blockchain endpoints, query blockchain networks, manage node deployments, or
  troubleshoot infrastructure issues.
metadata:
  mintlify-proj: chainstack
  version: "1.0"
---

# Chainstack Skill

## Product summary

Chainstack is a managed blockchain infrastructure platform supporting 70+ blockchain networks. Deploy RPC nodes in seconds, get instant endpoints, and access blockchain data via JSON-RPC APIs. Agents use Chainstack to create and manage blockchain nodes, configure security rules, monitor usage, and integrate blockchain connectivity into applications. Key resources: console at https://console.chainstack.com/, Platform API at https://docs.chainstack.com/reference/platform-api-getting-started, node RPC methods documented per protocol (e.g., Ethereum at https://docs.chainstack.com/reference/ethereum-getting-started).

## When to use

Reach for this skill when:
- A user needs to deploy a blockchain node or RPC endpoint for a specific network (Ethereum, Solana, Polygon, etc.)
- Configuring node access, security rules (IP allowlists, origin restrictions), or authentication
- Managing projects, networks, nodes, or billing within an organization
- Querying blockchain data via JSON-RPC methods (blocks, transactions, account balances, logs, etc.)
- Troubleshooting node connectivity, rate limits, or API errors
- Migrating from another blockchain infrastructure provider
- Setting up testnet faucets or requesting test tokens
- Monitoring node performance, request metrics, or usage statistics
- Integrating Chainstack endpoints into web3 applications (web3.js, ethers.js, web3.py, etc.)

## Quick reference

### Node types and deployment

| Node Type | Use Case | Deployment Time | Features |
|-----------|----------|-----------------|----------|
| Global Node | Production, worldwide access | <1 second | Load-balanced, auto-failover, access rules, Warp transactions |
| Unlimited Node | High-throughput workloads | Minutes | Unlimited RPS, dedicated resources |
| Dedicated Node | Custom requirements, archive data | Minutes | Full control, debug/trace APIs, monitoring |
| Trader Node | Deprecated (Dec 1, 2026) | N/A | Migrate to Global Node |

### Authentication methods

| Method | Format | Use Case |
|--------|--------|----------|
| Key-protected | `https://nd-xxx.p2pify.com/KEY` | API keys, programmatic access |
| Password-protected | `https://user:pass@nd-xxx.p2pify.com` | Basic auth, simple integrations |
| gRPC x-token | Passed in request metadata | Solana, Sui, high-performance protocols |
| Multichain token | Single token across multiple nodes | Managing multiple endpoints |

### Common RPC methods by protocol

**Ethereum/EVM chains**: `eth_blockNumber`, `eth_getBalance`, `eth_call`, `eth_sendRawTransaction`, `eth_getLogs`, `eth_getTransactionReceipt`

**Solana**: `getBalance`, `getBlock`, `getTransaction`, `getProgramAccounts`, `sendTransaction`, `simulateTransaction`

**Bitcoin**: `getblock`, `getrawtransaction`, `getblockchaininfo`, `sendrawtransaction`

**TON**: `getAddressInformation`, `getTransactions`, `runGetMethod`, `sendBoc`

### Billing and quotas

- **Request Units (RUs)**: 1 RU per full request, 2 RUs per archive request
- **Quota**: Allocated per subscription plan; extra usage auto-charges if enabled
- **Billing thresholds**: Auto-charge triggers at 80% and 100% of quota
- **Rate limits**: Vary by plan; check Throughput guidelines for RPS limits per protocol

### Access rules (Global Nodes only)

- **IP address rules**: Restrict to specific IPs (IPv4/IPv6, one per rule)
- **Origin rules**: Restrict to specific domains (supports wildcards: `*.example.com`)
- **Rule status**: New rules start deactivated; activate to enforce
- **Effect time**: Changes take ~10 seconds to propagate

## Decision guidance

### When to use Global Node vs Dedicated Node

| Scenario | Global Node | Dedicated Node |
|----------|------------|-----------------|
| Need instant deployment | ✓ | ✗ |
| Worldwide low-latency access | ✓ | ✗ |
| High-throughput sustained load | ✗ | ✓ |
| Need archive data or debug APIs | ✗ | ✓ |
| Budget-conscious, variable load | ✓ | ✗ |
| Custom monitoring/control | ✗ | ✓ |

### When to use IP rules vs Origin rules

| Scenario | IP Rules | Origin Rules |
|----------|----------|--------------|
| Backend API server | ✓ | ✗ |
| Browser-based dApp | ✗ | ✓ |
| Both frontend and backend | Separate nodes | Separate nodes |
| Server-side scripts/curl | ✓ | ✗ |
| Mobile app | ✓ | ✗ |

### Authentication: Key vs Password

| Factor | Key-Protected | Password-Protected |
|--------|---------------|-------------------|
| Security | Higher (unique per key) | Medium (shared credentials) |
| Rotation | Easy (generate new key) | Manual (change password) |
| Programmatic use | Preferred | Acceptable |
| Browser use | Not recommended | Acceptable |

## Workflow

### Deploy a node and get an endpoint

1. **Sign up or log in** to https://console.chainstack.com/
2. **Create or select a project** from the Projects page
3. **Add a network** to the project (select blockchain and mainnet/testnet)
4. **Deploy a node** by clicking "Create node" or the + button
5. **Select node type** (Global Node recommended for most use cases)
6. **Choose protocol and network** (e.g., Ethereum Mainnet)
7. **Review configuration** and click "Create node"
8. **Wait for status** to change from "Pending" to "Running" (seconds for Global Node)
9. **View credentials**: Click the node name, then copy the HTTPS or WSS endpoint and auth key/password
10. **Test the endpoint** with a curl request: `curl -X POST "ENDPOINT_URL" -H 'Content-Type: application/json' --data '{"method":"eth_blockNumber","jsonrpc":"2.0","params":[],"id":1}'`

### Add IP allowlist access rule

1. Navigate to your project → network → node
2. Click the **Security** tab
3. Click **+ Add** to create a new rule
4. Select **IP address** as the rule type
5. Enter the IP address (IPv4 or IPv6, one per rule)
6. Click **Create**
7. Hover over the rule, click the edit pencil, and click **Activate**
8. Wait ~10 seconds for the rule to take effect

### Add origin allowlist access rule

1. Navigate to your project → network → node
2. Click the **Security** tab
3. Click **+ Add** to create a new rule
4. Select **Allowed origin** as the rule type
5. Enter the domain (e.g., `myapp.com` or `*.myapp.com`; no `https://` or path)
6. Click **Create**
7. Hover over the rule, click the edit pencil, and click **Activate**
8. Wait ~10 seconds for the rule to take effect

### Monitor node usage and metrics

1. Navigate to your project → network → node
2. Click the **Metrics** tab to view:
   - **Requests made**: Total HTTP and WebSocket requests over time
   - **Method calls**: Breakdown of RPC methods called (HTTP only)
   - **Response codes**: HTTP status code distribution
3. Select a timeframe (1 hour, 6 hours, 12 hours, 24 hours, 7 days)
4. Download aggregate data by clicking the hamburger menu in "Requests made"

### Integrate endpoint into a web3 application

1. **Get your endpoint URL** from the node details page
2. **Choose a web3 library** (web3.js, ethers.js, web3.py, etc.)
3. **Initialize the provider** with your Chainstack endpoint:
   - **web3.js**: `new Web3('https://YOUR_ENDPOINT')`
   - **ethers.js**: `new ethers.JsonRpcProvider('https://YOUR_ENDPOINT')`
   - **web3.py**: `Web3(Web3.HTTPProvider('https://YOUR_ENDPOINT'))`
4. **Use the provider** to call RPC methods (e.g., `getBalance`, `sendTransaction`)
5. **Handle errors** with retry logic and exponential backoff for transient failures

### Troubleshoot common errors

| Error | Cause | Fix |
|-------|-------|-----|
| 401 Unauthorized | Wrong endpoint key or password | Verify credentials in node details |
| 403 Forbidden | Access rule blocked request | Check IP/origin rules; ensure request matches allowed values |
| 429 Too Many Requests | Hit RPS or connection limit | Reduce request rate; consider Unlimited Node for sustained load |
| 504 Gateway Timeout | Node didn't respond in time | Paginate large queries (e.g., eth_getLogs); move to Dedicated Node for heavy workloads |
| 502 Bad Gateway | Node unreachable | Retry with backoff; contact support if persistent |

## Common gotchas

- **Origin rules block non-browser requests**: Origin rules reject requests without an `Origin` header (server-side code, curl, scripts). Use separate nodes for browser and backend, or use IP rules for backend.
- **Access rules take ~10 seconds to activate**: New or modified rules don't take effect immediately. Wait before testing.
- **Trader Nodes deprecated**: Trader Nodes are being phased out (Dec 1, 2026). Migrate workloads to Global Nodes now.
- **Archive requests cost 2 RUs**: Archive methods (historical state queries) consume twice the RUs of full requests. Check Request units documentation for your protocol.
- **Snapshot-bootstrapped nodes need 2× storage**: Ethereum, Optimism, Arbitrum, Robinhood, and Sui nodes temporarily need double storage during initial sync (snapshot download + extraction). Reclaim space after extraction.
- **Multichain endpoints require explicit attachment**: Nodes must be attached to a multichain endpoint to use a single auth token across multiple nodes.
- **Rate limits vary by protocol and program**: Solana's getProgramAccounts has per-program rate limits based on account count. Check Throughput guidelines for your protocol.
- **Password-protected endpoints expose credentials in URLs**: Avoid using password auth in client-side code; use key-protected endpoints or IP rules instead.
- **Batch requests have size limits**: Default request body cap is 1 MB. Split large batches or paginate queries.
- **WebSocket connections require WSS endpoints**: Use `wss://` endpoints for WebSocket subscriptions, not `https://`.

## Verification checklist

Before submitting work with Chainstack:

- [ ] Node status is "Running" (not "Pending" or "Failed")
- [ ] Endpoint URL is correct (HTTPS or WSS format matches use case)
- [ ] Authentication credentials (key or password) are valid and not expired
- [ ] Access rules (if configured) match the request source (IP or origin)
- [ ] RPC method is supported on the deployed protocol (check protocol-specific docs)
- [ ] Request payload is valid JSON-RPC 2.0 format
- [ ] Quota usage is within plan limits (check Billing → Usage details)
- [ ] Rate limits are not exceeded (check Throughput guidelines for your protocol)
- [ ] Error handling and retry logic are in place for transient failures
- [ ] Sensitive credentials are stored in environment variables, not hardcoded
- [ ] WebSocket subscriptions use WSS endpoints, not HTTPS

## Resources

- **Full documentation index**: https://docs.chainstack.com/llms.txt (compact index) or https://docs.chainstack.com/llms-full.txt (complete portal)
- **Platform API reference**: https://docs.chainstack.com/reference/platform-api-getting-started
- **Blockchain RPC methods by protocol**: https://docs.chainstack.com/reference/blockchain-apis (links to Ethereum, Solana, Polygon, Bitcoin, and 60+ other networks)
- **Pricing and request units**: https://docs.chainstack.com/docs/pricing-introduction
- **Node types and configurations**: https://docs.chainstack.com/docs/protocols-configurations

---

> For additional documentation and navigation, see: https://docs.chainstack.com/llms.txt