Monad

CRITICAL

⚠️ Always verify addresses using the explorer before interacting with smart contracts. Never hallucinate a smart contract address, wrong addresses can lead to loss of funds.

Make sure you have zero doubts about which network the user is asking the address for whether mainnet or testnet, if you are unsure then ask the user. Do not provide mainnet address when a testnet address was asked for.

How to verify if a smart contract has code on a network.

If Foundry toolkit is installed.

Monad Mainnet

# Check bytecode exists
cast code [smart_contract_address] --rpc-url https://rpc.monad.xyz

Monad Testnet

# Check bytecode exists
cast code [smart_contract_address] --rpc-url https://testnet-rpc.monad.xyz

If Foundry toolkit is not installed you can call "eth_getCode" RPC method on the respective RPC endpoint for the network with the smart contract address and verify using the response.

Canonical contracts (on Monad mainnet)

AI & Agent Standards

ERC-8004 (same addresses for Monad mainnet and testnet)

Bridged Assets Dollar-related (on Monad mainnet)

Bridged Assets ETH-related (on Monad mainnet)

Bridged Assets BTC-related (on Monad mainnet)

Bridged Assets - Others (on Monad mainnet)

Natively-Issued Assets (on Monad mainnet)

MON on other blockchains

Protocols repo

The protocols repo contains smart contract address (testnet and mainnet) for well known protocols and projects in the monad ecosystem.

If you need an address that is not found from the tables above check the protocols repo for the smart contract address.

Protocol repo GitHub URL: https://github.com/monad-crypto/protocols

Addresses in protocols repo are organized by testnet and mainnet and each protocol has it's own file.

For example:

Smart contract addresses for Clober protocol on Monad mainnet is in file: protocols/mainnet/clober.jsonc

Each file has a JSON object with property "addresses" which is object with items as "name" and address of each smart contract associated with the respected protocol.

Similarly for testnet, the route is protocols/testnet/[protocol_name].json

Token list repo

The token list repo contains smart contract address (mainnet only) for well known tokens in the monad ecosystem.

If you need an address for a token that is not found from the tables above check the token list repo for smart contract address.

Token list repo GitHub URL: https://github.com/monad-crypto/token-list

Addresses in token list repo are organized by token names in folders, there is a mainnet folder inside which there are folders with token names inside each folder is a json with the address.

CRITICAL

⚠️ After looking at all the available options above, if you are still not able to find the address ask the user for it but do not at all hallucinate an address and do not provide mainnet address when a testnet address was asked for.

重要提示

⚠️ 在与智能合约交互之前，务必通过区块浏览器验证地址。绝不要凭空捏造智能合约地址，错误的地址可能导致资金损失。

请确保完全明确用户询问的是主网还是测试网的地址，如果不确定请向用户确认。不要在用户询问测试网地址时提供主网地址。

如何验证智能合约在某个网络上是否有代码

如果已安装 Foundry 工具包：

Monad 主网

# Check bytecode exists
cast code [smart_contract_address] --rpc-url https://rpc.monad.xyz

Monad 测试网

# Check bytecode exists
cast code [smart_contract_address] --rpc-url https://testnet-rpc.monad.xyz

如果未安装 Foundry 工具包，你可以在相应网络的 RPC 端点上调用 eth_getCode RPC 方法，传入智能合约地址并通过返回结果进行验证。

规范合约（Monad 主网）

AI 与代理标准

ERC-8004（Monad 主网和测试网地址相同）

桥接资产 — 美元相关（Monad 主网）

桥接资产 — ETH 相关（Monad 主网）

桥接资产 — BTC 相关（Monad 主网）

桥接资产 — 其他（Monad 主网）

原生发行资产（Monad 主网）

其他区块链上的 MON

协议仓库

协议仓库包含 Monad 生态系统中知名协议和项目的智能合约地址（测试网和主网）。

如果在上方表格中找不到所需地址，请在协议仓库中查找智能合约地址。

协议仓库 GitHub 地址：https://github.com/monad-crypto/protocols

协议仓库中的地址按测试网和主网分类组织，每个协议有各自的文件。

例如：

Clober 协议在 Monad 主网上的智能合约地址位于文件：protocols/mainnet/clober.jsonc

每个文件包含一个 JSON 对象，其中 addresses 属性是一个对象，包含相应协议每个智能合约的名称和地址。

测试网的路径类似：protocols/testnet/[protocol_name].json

代币列表仓库

代币列表仓库包含 Monad 生态系统中知名代币的智能合约地址（仅限主网）。

如果在上方表格中找不到所需代币地址，请在代币列表仓库中查找智能合约地址。

代币列表仓库 GitHub 地址：https://github.com/monad-crypto/token-list

代币列表仓库中的地址按代币名称以文件夹形式组织，其中有一个 mainnet 文件夹，内部按代币名称分文件夹，每个文件夹中包含一个带有地址的 JSON 文件。

重要提示

⚠️ 查看完以上所有可用选项后，如果仍然找不到所需地址，请向用户询问，但绝对不要凭空捏造地址，也不要在用户询问测试网地址时提供主网地址。

Asynchronous Execution

Monad decouples consensus from execution. Nodes agree on transaction ordering without executing transactions first. Execution runs in parallel with consensus rather than blocking it.

What this means for developers:

• Consensus operates with a 3-block delayed state view (D=3). The state root included in a block is from 3 blocks prior.
• Newly funded accounts cannot send transactions until their funding transfer is `D` blocks old (~1.2 seconds after the transaction is included). This is because consensus validates gas budgets against the delayed state, and the funding won't be visible yet.
• Workaround: Use a smart contract to atomically combine funding and spending in a single transaction, bypassing the delay.
• Despite the lag, the true state is deterministic as soon as ordering is determined — execution simply catches up.
• eth_call and eth_estimateGas simulate against speculatively executed state, so they return accurate results even though execution technically lags consensus.

Reference: https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution

异步执行

Monad 将共识与执行解耦。节点在不先执行交易的情况下就交易排序达成一致。执行与共识并行运行，而不是阻塞共识。

这对开发者意味着什么：

• 共识使用延迟 3 个区块的状态视图（D=3）。区块中包含的状态根来自 3 个区块之前。
• 新充值账户在其资金转入交易经过 `D` 个区块后才能发送交易（交易被包含后约 1.2 秒）。这是因为共识根据延迟状态验证 Gas 预算，而资金在此之前尚不可见。
• 解决方案： 使用智能合约在单笔交易中原子性地组合充值和消费操作，从而绕过延迟。
• 尽管存在延迟，一旦排序确定，真实状态就是确定性的 — 执行只是在追赶进度。
• eth_call 和 eth_estimateGas 基于推测性执行的状态进行模拟，因此即使执行在技术上滞后于共识，它们仍返回准确的结果。

参考：https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution

Block States

Monad blocks progress through four states. Each maps to a familiar Ethereum JSON-RPC tag:

What this means for developers:

• Use "latest" for fast reads (proposed state, speculative).
• Use "safe" for data that has validator backing but could theoretically revert.
• Use "finalized" for irreversible actions (e.g. confirming a withdrawal).
• Proposed blocks undergo speculative execution. In rare cases, apps consuming real-time data may see data from blocks that don't become canonical.
• With 400ms block time and 800ms finality, the progression through these states is very fast.

Reference: https://docs.monad.xyz/monad-arch/consensus/block-states

区块状态

Monad 区块经历四个状态。每个状态映射到一个常见的以太坊 JSON-RPC 标签：

这对开发者意味着什么：

• 使用 "latest" 进行快速读取（提议状态，推测性的）。
• 使用 "safe" 获取有验证者支持但理论上仍可能回退的数据。
• 使用 "finalized" 进行不可逆操作（例如确认提款）。
• 提议区块会进行推测性执行。在极少数情况下，消费实时数据的应用可能会看到来自未成为规范链的区块的数据。
• 由于 400 毫秒的出块时间和 800 毫秒的最终确认时间，这些状态之间的转换非常快。

参考：https://docs.monad.xyz/monad-arch/consensus/block-states

EIP-7702 (Delegated EOAs)

EIP-7702 lets EOAs delegate code execution to a smart contract, gaining smart wallet capabilities (multisig, social recovery, session keys, gas sponsorship) without migrating to a new account.

How it works:

1. EOA signs an authorization message pointing to a contract address. 2. A type 0x04 transaction submits this authorization (can be sent by the EOA or a third party / gas sponsor). 3. The EOA becomes "delegated" and behaves as if it has the delegated contract's code.

Monad-specific behaviors:

• Balance floor: Delegated EOAs cannot have transactions reduce their balance below 10 MON. If the balance is already below 10 MON but unchanged or increased by the transaction, it succeeds.
• No CREATE/CREATE2: Contract code executing within a delegated EOA's context cannot use CREATE or CREATE2 opcodes (the call frame reverts). This prevents nonce manipulation. Standard contract-creation transactions from the EOA are still allowed.
• Delegations persist indefinitely until explicitly cleared (send a 0x04 transaction with 0x0000...0000 as the delegate address).

viem example:

import { createWalletClient, http } from 'viem'
import { monadTestnet } from 'viem/chains'
import { privateKeyToAccount } from 'viem/accounts'

const account = privateKeyToAccount('0x...')

const walletClient = createWalletClient({
  account,
  chain: monadTestnet,
  transport: http(),
})

const authorization = await walletClient.signAuthorization({
  account,
  contractAddress: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2',
})

const hash = await walletClient.sendTransaction({
  authorizationList: [authorization],
  data: '0xdeadbeef',
  to: walletClient.account.address,
})

Reference: https://docs.monad.xyz/developer-essentials/eip-7702

EIP-7702（委托 EOA）

EIP-7702 允许 EOA 将代码执行委托给智能合约，从而获得智能钱包功能（多签、社交恢复、会话密钥、Gas 赞助），而无需迁移到新账户。

工作原理：

1. EOA 签署一条指向合约地址的授权消息。 2. 通过类型 0x04 的交易提交此授权（可由 EOA 自身或第三方/Gas 赞助者发送）。 3. EOA 变为"已委托"状态，表现得如同拥有被委托合约的代码。

Monad 特定行为：

• 余额下限： 委托 EOA 的交易不能将其余额降低到 10 MON 以下。如果余额已低于 10 MON，但交易未减少或增加了余额，则交易成功。
• 禁止 CREATE/CREATE2： 在委托 EOA 上下文中执行的合约代码不能使用 CREATE 或 CREATE2 操作码（调用帧将回退）。这是为了防止 nonce 被操纵。EOA 发起的标准合约创建交易仍然允许。
• 委托将无限期持续，直到被明确清除（发送一笔 0x04 类型交易，将委托地址设为 0x0000...0000）。

viem 示例：

import { createWalletClient, http } from 'viem'
import { monadTestnet } from 'viem/chains'
import { privateKeyToAccount } from 'viem/accounts'

const account = privateKeyToAccount('0x...')

const walletClient = createWalletClient({
  account,
  chain: monadTestnet,
  transport: http(),
})

const authorization = await walletClient.signAuthorization({
  account,
  contractAddress: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2',
})

const hash = await walletClient.sendTransaction({
  authorizationList: [authorization],
  data: '0xdeadbeef',
  to: walletClient.account.address,
})

参考：https://docs.monad.xyz/developer-essentials/eip-7702

Execution Events and Consensus Events

Monad emits two categories of events through its real-time data feeds:

Consensus events announce block state transitions:

• BLOCK_START — Block execution begins (Proposed state). Includes block tag, round, epoch.
• BLOCK_QC — Block received a quorum certificate (Voted state).
• BLOCK_FINALIZED — Block is finalized (irreversible).
• BLOCK_VERIFIED — State root verified by supermajority.

Execution events are EVM trace data (logs, state changes) emitted during block processing. They are speculative — the block they belong to might not become canonical.

What this means for developers:

• If consuming real-time data, always track consensus events to know which block state you're seeing.
• Data from BLOCK_START is speculative. Only treat data as final after BLOCK_FINALIZED.
• Block identification requires both a consensus ID and proposed block number (communicated via "block tags").

Reference: https://docs.monad.xyz/execution-events/consensus-events

执行事件和共识事件

Monad 通过其实时数据流发出两类事件：

共识事件通告区块状态转换：

• BLOCK_START — 区块开始执行（Proposed 状态）。包含区块标签、轮次、纪元。
• BLOCK_QC — 区块收到法定人数证书（Voted 状态）。
• BLOCK_FINALIZED — 区块已最终确认（不可逆）。
• BLOCK_VERIFIED — 状态根已由超多数验证者验证。

执行事件是区块处理过程中产生的 EVM 追踪数据（日志、状态变更）。它们是推测性的 — 其所属的区块可能不会成为规范链的一部分。

这对开发者意味着什么：

• 如果消费实时数据，务必追踪共识事件以了解当前看到的是哪个区块状态。
• 来自 BLOCK_START 的数据是推测性的。只有在 BLOCK_FINALIZED 之后才应将数据视为最终确认。
• 区块识别需要同时使用共识 ID 和提议区块号（通过"区块标签"传达）。

参考：https://docs.monad.xyz/execution-events/consensus-events

Parallel Execution

Monad executes transactions in parallel using optimistic concurrency control, but the final result is identical to sequential Ethereum execution. Transaction ordering within a block is preserved.

What this means for developers:

• No code changes required. Existing Solidity contracts work as-is. The execution semantics are identical to Ethereum.
• Monad starts executing transactions optimistically before predecessors complete. It tracks reads and compares them against prior writes. If a conflict is detected, the transaction is re-executed with correct state.
• Expensive computations like signature recovery and state lookups are cached, so re-execution overhead is minimal.
• Contracts that touch frequently-updated storage slots (e.g. a single global counter) may cause more re-executions, but this is handled transparently — it only affects node performance, not correctness.

Reference: https://docs.monad.xyz/monad-arch/execution/parallel-execution

并行执行

Monad 使用乐观并发控制并行执行交易，但最终结果与以太坊顺序执行完全一致。区块内的交易排序保持不变。

这对开发者意味着什么：

• 无需修改代码。 现有的 Solidity 合约可以直接使用。执行语义与以太坊完全相同。
• Monad 在前序交易完成之前就开始乐观执行交易。它追踪读取操作并与先前的写入操作进行比较。如果检测到冲突，交易将使用正确的状态重新执行。
• 昂贵的计算（如签名恢复和状态查找）会被缓存，因此重新执行的开销很小。
• 频繁更新存储槽的合约（例如单一的全局计数器）可能会导致更多的重新执行，但这是透明处理的 — 它只影响节点性能，不影响正确性。

参考：https://docs.monad.xyz/monad-arch/execution/parallel-execution

Real-Time Data Sources

Monad's high throughput (~10,000 tps) makes traditional JSON-RPC polling impractical. Three real-time data sources are available:

1. Geth-Compatible WebSocket Events

• Standard eth_subscribe with newHeads and logs.
• Data publishes at Proposed state.
• Available via third-party RPC providers (Alchemy, QuickNode, etc.).
• Best for: apps migrating from Ethereum with minimal changes.

2. Monad Extended WebSocket Events

• monadNewHeads and monadLogs subscriptions.
• Data publishes at Proposed state (earlier than standard).
• Includes consensus progression tracking.
• Best for: apps that need the lowest latency and can handle speculative data.

3. Execution Events SDK (C/C++/Rust)

• Transaction-level granularity with logs, call frames, and state reads/writes.
• Fastest option — powers the other two sources internally.
• Requires running a custom program on the same host as a Monad node.
• Best for: indexers, analytics, MEV, and high-performance infrastructure.

Which to choose:

• Most app developers should use Source 1 (Geth-compatible) via their RPC provider.
• Use Source 2 if you need earlier data and understand speculative execution.
• Use Source 3 only if you run your own node and need maximum performance.

Reference: https://docs.monad.xyz/monad-arch/realtime-data/data-sources

实时数据源

Monad 的高吞吐量（约 10,000 tps）使传统的 JSON-RPC 轮询变得不切实际。有三种实时数据源可用：

1. Geth 兼容 WebSocket 事件

• 标准的 eth_subscribe，支持 newHeads 和 logs。
• 数据在 Proposed 状态时发布。
• 通过第三方 RPC 提供商（Alchemy、QuickNode 等）提供。
• 最适合：从以太坊迁移且需要最小改动的应用。

2. Monad 扩展 WebSocket 事件

• monadNewHeads 和 monadLogs 订阅。
• 数据在 Proposed 状态时发布（比标准更早）。
• 包含共识进展追踪。
• 最适合：需要最低延迟且能处理推测性数据的应用。

3. 执行事件 SDK（C/C++/Rust）

• 交易级别的粒度，包含日志、调用帧和状态读写。
• 最快的选项 — 在内部驱动其他两种来源。
• 需要在与 Monad 节点相同的主机上运行自定义程序。
• 最适合：索引器、分析、MEV 和高性能基础设施。

如何选择：

• 大多数应用开发者应通过 RPC 提供商使用来源 1（Geth 兼容）。
• 如果需要更早的数据且了解推测性执行，使用来源 2。
• 仅当运行自己的节点且需要最大性能时，使用来源 3。

参考：https://docs.monad.xyz/monad-arch/realtime-data/data-sources

Reserve Balance

Reserve balance is a safety mechanism that prevents transactions from failing due to insufficient gas in the asynchronous execution model. It sets a 10 MON floor per EOA.

What this means for developers:

• Most apps won't be affected. This only matters for accounts with low MON balances.
• Transactions revert if an account's ending balance (before gas refunds) drops below min(starting_balance, 10 MON).
• Low-balance accounts (below 10 MON) can only send one transaction every 3 blocks (~1.2 seconds).
• An emptying transaction exception exists: undelegated accounts that sent no other transactions in the past 3 blocks can spend below the reserve. This allows users to fully withdraw their balance.
• EIP-7702 delegated accounts cannot use the emptying exception — they are always subject to the 10 MON floor when their balance decreases.
• For transaction senders, consensus enforces a cumulative gas budget across all inflight transactions (past 3 blocks): min(10 MON, lagged_state_balance).

Reference: https://docs.monad.xyz/developer-essentials/reserve-balance

储备余额

储备余额是一种安全机制，用于防止交易在异步执行模型中因 Gas 不足而失败。它为每个 EOA 设置了 10 MON 的余额下限。

这对开发者意味着什么：

• 大多数应用不会受到影响。 这仅对 MON 余额较低的账户有影响。
• 如果账户的最终余额（Gas 退款之前）低于 min(起始余额, 10 MON)，交易将回退。
• 低余额账户（低于 10 MON）每 3 个区块（约 1.2 秒）只能发送一笔交易。
• 存在清空交易例外：未委托的账户如果在过去 3 个区块内没有发送其他交易，可以消费低于储备余额的金额。这允许用户完全提取其余额。
• EIP-7702 委托账户不能使用清空例外 — 当其余额减少时，始终受 10 MON 下限约束。
• 对于交易发送者，共识在所有进行中的交易（过去 3 个区块）上强制执行累计 Gas 预算：min(10 MON, 延迟状态余额)。

参考：https://docs.monad.xyz/developer-essentials/reserve-balance

Monad 与以太坊兼容，但其架构引入了开发者必须了解的行为差异。请仅获取与当前任务相关的参考资料。

按任务获取

概要

• 异步执行： 共识与执行解耦。状态视图有 3 个区块的延迟。新充值账户需等待约 1.2 秒才能发送交易。
• 并行执行： 乐观并发控制 — 结果与以太坊完全一致。无需修改合约。
• 区块状态： Proposed → Voted → Finalized → Verified。分别映射到 latest / safe / finalized。
• 储备余额： 每个 EOA 有 10 MON 的余额下限。低余额账户每约 1.2 秒限发送 1 笔交易。
• EIP-7702： EOA 可委托给合约以获得智能钱包功能。10 MON 下限适用。在委托上下文中不可使用 CREATE/CREATE2。
• 实时数据： 3 种来源 — Geth 兼容 WS、Monad 扩展 WS、执行事件 SDK。大多数应用使用来源 1。
• 执行事件： 共识事件追踪区块状态转换。执行事件是推测性的 EVM 追踪数据。

Monad 的 Gas 定价兼容 EIP-1559，但在关键方面与以太坊不同。如果你正在构建提交交易、估算 gas 或显示 gas 费用的应用，你需要了解这些差异。

核心区别：Monad 按 Gas 上限收费，而非按实际消耗收费

在以太坊上，用户为交易实际消耗的 gas 付费。在 Monad 上，用户根据设置的 gas 上限 付费：

gas_paid = gas_limit * price_per_gas

这是因为 Monad 使用异步执行——出块者在执行交易之前就构建区块，因此在交易被纳入时实际 gas 消耗量是未知的。这可以防止 DOS 攻击，即交易声称需要很少的 gas 但实际消耗大量计算资源。

对开发者的影响：

• 设置不必要的高 gas 上限会直接让用户多花 MON。
• 始终设置紧凑、准确的 gas 上限，特别是对于已知固定成本的交易。
• 对于原生 MON 转账，gas 成本始终为 21,000。请硬编码此值，而不是依赖 eth_estimateGas。

EIP-1559 交易定价

Monad 使用 type 2 (EIP-1559) 交易：

price_per_gas = min(base_price_per_gas + priority_price_per_gas, max_price_per_gas)

用户在签名时指定两个值：

• priority_price_per_gas — 用于在区块内优先排序交易的小费
• max_price_per_gas — 总 gas 价格的安全上限

网络控制 base_price_per_gas，同一区块内所有交易的该值相同。

区块和交易限制

这些值远高于以太坊的 30M 区块 gas 上限，这意味着 Monad 区块可以容纳更多交易。

基础费用控制器

Monad 的基础费用控制器与以太坊不同。它上涨更慢，下降更快，以防止区块空间利用率不足导致的定价过高。

控制器参数：

• max_step_size = 1/28
• target = 160M gas（区块容量的 80%）
• beta = 0.96
• epsilon = 160M

基础费用在每个区块更新，使用指数调整，基于区块相对于目标的填充程度。该公式使用指数平滑（beta = 0.96）来跟踪区块填充度的历史方差，产生比以太坊更简单机制更平滑的费用过渡。

在实践中，这意味着 Monad 上的 gas 价格更稳定，在价格飙升后恢复得更快。

交易排序

默认的 Monad 客户端使用优先 Gas 拍卖来排序交易——交易按总 gas 价格（基础费用 + 优先费用）降序排列。

开发者指南

对已知成本始终设置明确的 Gas 上限

对于具有固定 gas 成本的操作，在提交给钱包之前明确设置 gas 上限：

// 好的做法：为原生转账设置明确的 gas 上限
const tx = {
  to: recipient,
  value: parseEther("1.0"),
  gasLimit: 21000n,
};

这很重要，因为一些钱包（如 MetaMask）使用 eth_estimateGas 来确定 gas 上限。如果该调用回滚（例如合约调用会失败），钱包可能会回退到一个非常高的 gas 上限。在 Monad 上，用户将为整个膨胀的上限付费，因为 gas 是按上限收费的，而非按实际使用量收费。

前端代码中的 Gas 估算

使用 viem 或 wagmi 估算 gas 时，请记住估算值就是用户实际支付的金额，而不是一个下限。如果需要，只添加一个小的缓冲：

// 如果必须估算，保持较小的缓冲
const estimate = await publicClient.estimateGas({ ... });
const gasLimit = estimate + (estimate / 10n); // 最多 10% 的缓冲

向用户显示 Gas 费用

在 UI 中显示 gas 费用时，从 gas 上限计算（而不是其他链上收据中的"已使用 gas"）：

const gasCost = gasLimit * gasPrice;

智能合约注意事项

• Monad 的 30M 交易 gas 上限与以太坊的区块 gas 上限相同，因此单笔交易可以非常大。
• 优化你的合约以在 Monad 上使用更少的 gas——这直接为用户省钱，因为他们为上限付费，更紧凑的估算意味着更紧凑的上限。
• 如果你的合约具有可预测 gas 成本的函数，请记录它们以便前端可以设置明确的上限。

操作码定价差异

Monad 上调了部分操作码的价格，而不是对所有操作码进行折扣。这在最小干扰的情况下实现了相同的相对效果。这些变化反映了 Monad 高性能架构中不同的资源稀缺性，特别是基于磁盘的状态操作。

冷状态访问价格大幅提高

受影响的操作码：

• 账户访问：BALANCE、EXTCODESIZE、EXTCODECOPY、EXTCODEHASH、CALL、CALLCODE、DELEGATECALL、STATICCALL、SELFDESTRUCT
• 存储访问：SLOAD、SSTORE

对开发者的影响：

• 访问大量冷存储槽或调用大量外部合约的合约在 Monad 上成本会显著增加。
• 热访问与以太坊完全相同，因此在同一交易内重复访问同一存储槽/账户不会产生额外费用。
• 批量操作中先冷访问一次存储槽然后重复热访问是没问题的。但跨多个不同存储槽进行单次冷读取的模式会更昂贵。
• 如果你的合约在单次调用中读取多个不同的存储槽，在 Monad 上的 gas 估算会更高。设置 gas 上限时请考虑这一点。

预编译合约重新定价

加密预编译合约在 Monad 上的成本是 2-5 倍：

对开发者的影响：

• 大量依赖签名验证（ecRecover）的合约在这些操作上将消耗 2 倍的 gas。
• ZK 相关操作（ecMul、ecPairing、point evaluation）贵 4-5 倍。如果你的合约进行链上 ZK 证明验证，以太坊的 gas 估算将会有很大偏差。
• 如果你的合约使用了这些预编译合约，在计算 gas 上限时请将这些更高的成本考虑在内。

envio-cloud — behavioral notes

CLI syntax is available via envio-cloud --help and envio-cloud <command> --help. This file covers what --help doesn't: guardrails, gotchas, and context for how the CLI fits into the broader workflow.

Source of truth for the CLI itself: https://docs.envio.dev/docs/HyperIndex/envio-cloud-cli

Install and auth — never do these for the user

• Don't install the CLI for the user. The command is npm install -g envio-cloud (or npx envio-cloud <command> to run without installing) — tell them, don't run it.
• `envio-cloud` requires `gh` (GitHub CLI) to be installed and authenticated, since Envio Cloud deploys from GitHub. If gh is missing or not authenticated, tell the user to install it (brew install gh on macOS) and run gh auth login themselves — both require browser interaction.
• Don't run `envio-cloud login` for the user. It opens a browser tab on envio.dev and only the user can complete it. Sessions last 30 days.
• `envio-cloud token` is the canonical session check. Exit 0 = valid session. The monskills hook gates envio-cloud commands on this; use it whenever you need to know if the user is authenticated.

GraphQL endpoint — what the frontend talks to

envio-cloud deployment endpoint <indexer> <commit> <org> prints the URL the frontend queries. The indexer is useless to the frontend until this URL is wired in. After a healthy deployment, resolve this URL and write it to the frontend's env file (typically web/.env.local as NEXT_PUBLIC_INDEXER_URL) — don't hand the URL back to the user to paste themselves. See envio-cloud-workflows.md for the full wiring recipe.

Gotchas:

• Use the URL exactly as printed. Don't rewrite it, add a trailing slash, or strip query parts.
• `--cluster` override is rare. Only pass it if the user explicitly asked for a non-default cluster. Valid values: hyper, hypertierchicago, ip-projects, prodaws, staging.
• `-q` suppresses informational messages — use it when capturing the URL into a shell variable.
• You can only resolve endpoints for orgs you are a member of (exit 1 otherwise).
• The URL is computed locally from deployment parameters; only the cluster is resolved via the API. Fast, but still requires authentication.

Frontend wiring (Next.js + fetch) — adapt the env var name for non-Next.js stacks (VITE_INDEXER_URL for Vite, etc.):

// web/.env.local
// NEXT_PUBLIC_INDEXER_URL=<URL printed by `envio-cloud deployment endpoint`>

// web/lib/indexer.ts
export async function query<T>(gql: string, variables?: Record<string, unknown>): Promise<T> {
  const res = await fetch(process.env.NEXT_PUBLIC_INDEXER_URL!, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query: gql, variables }),
  });
  const { data, errors } = await res.json();
  if (errors) throw new Error(errors[0]?.message ?? 'GraphQL error');
  return data as T;
}

Query shape comes from indexer/schema.graphql — whatever entities the handlers write, the frontend can read by the same names. Don't reach for Apollo/urql unless the user asks; fetch is enough.

Environment variables

• Never echo secret values back to the user. If you read env vars via envio-cloud indexer env list, don't include the values in your response.
• Setting an env var does not restart running deployments. Follow up with envio-cloud deployment restart <indexer> <commit> if the change needs to take effect on an active deployment.

IP allowlist — order matters

Enabling the allowlist without adding the user's current IP first will lock them out of their own indexer's API. Always:

1. Add the user's current IP via envio-cloud indexer security add-ip <ip> 2. Then enable via envio-cloud indexer security enable

Ask the user for their IP — don't assume.

Indexer deletion is irreversible

envio-cloud indexer delete <name> <org> cannot be undone. Confirm by name with the user before running it. Don't add retry logic around it.

Exit codes

Don't rely on stdout content alone — check the exit code.

Envio Cloud — workflow recipes

Opinionated sequences for common indexer tasks. Each recipe assumes the user is already logged in (envio-cloud token exit 0).

First deploy

Use when: the user wants to take a local HyperIndex project and put it on Envio Cloud for the first time.

1. Confirm the repo is pushed to GitHub. Envio Cloud deploys from GitHub, not from local files. If the project is local-only, stop and ask the user to push it first. 2. Set the org context (once):

   envio-cloud config set-org <org>

Ask the user for their org slug if you don't know it. Don't guess. 3. Register the indexer:

   envio-cloud indexer add --name <name> --repo <owner/repo>

The --repo argument is owner/repo, not a full URL. 4. Wait for the deployment to build. The add command returns a commit SHA. Poll with:

   envio-cloud deployment status <name> <commit>

Don't busy-loop — wait at least 5s between polls. If it stays pending for >5 minutes, check logs. 5. Wait for the initial build to finish, then push an empty commit to guarantee the indexer starts. Envio Cloud has a quirk where indexer add sometimes creates the deployment but never starts the indexer — the deployment looks "deployed" in status but the indexer never advances past startBlock. Empirically, pushing an empty commit after the first build completes always kicks off a fresh build that does start the indexer. Do this unconditionally rather than gating on a stuck-detection check — it costs one extra build but removes the failure mode entirely.

First, wait for the initial deployment to finish building (don't push the empty commit while the first build is still in progress, or you'll race it):

   envio-cloud deployment status <name> <commit>

Once the build is complete, push the empty commit from the indexer repo:

   (cd indexer && git commit --allow-empty -m "trigger envio-cloud rebuild" && git push)

Envio Cloud auto-picks up the new commit and supersedes the previous deployment. Grab the new SHA and use it for the rest of this recipe:

   NEW_COMMIT=$(cd indexer && git rev-parse --short HEAD)

Then verify the new deployment is actually indexing. The authoritative check is the indexer's own _meta (one entry per chain), not the control-plane metrics. Resolve the endpoint and query:

   INDEXER_URL=$(envio-cloud deployment endpoint <name> "$NEW_COMMIT" <org> -q)
   curl -sf "$INDEXER_URL" \
     -H 'Content-Type: application/json' \
     -d '{"query": "{ _meta { chainId startBlock progressBlock sourceBlock isReady readyAt eventsProcessed } }"}' \
     | jq '.data._meta'

Interpret the result:

• Healthy: isReady: true, readyAt has a timestamp, and progressBlock is at or approaching sourceBlock (which is the indexer's own view of the chain tip — use it in-band instead of a separate RPC call). Gap between progressBlock and sourceBlock = still syncing historical blocks; it will close over time.
• Do NOT treat `eventsProcessed: 0` as stuck. A contract that has emitted no events since startBlock will sit at zero forever while the indexer is perfectly healthy.

Do this transparently — the user shouldn't have to know about the empty-commit workaround. 6. Promote to production when indexing is actually progressing:

   envio-cloud deployment promote <name> "$NEW_COMMIT"

Use the post-empty-commit SHA ($NEW_COMMIT from step 5) — that's the deployment that's actually indexing. Only promote after confirming the indexer is syncing and returning data as expected. 7. Wire the GraphQL URL into the frontend automatically (see "Get the GraphQL endpoint URL" recipe below). If the project has a frontend (e.g. web/), resolve the endpoint and write it to web/.env.local as NEXT_PUBLIC_INDEXER_URL without handing a URL back to the user to paste themselves. 8. Report the indexer name and promoted commit to the user so they can reference it later.

Deployment exists but never started indexing

Use when: deployment status looks healthy/deployed but the indexer's _meta shows isReady: false, readyAt: null, and progressBlock == startBlock. This is a known Envio Cloud quirk — the deployment was created but the indexer process never actually kicked off. It's distinct from a failing deploy (which shows error status in deployment status / stack traces in logs) and from slow syncing (which has progressBlock increasing toward sourceBlock).

Fix it by pushing an empty commit to the indexer repo so Envio Cloud triggers a fresh build:

1. Confirm the symptom first — don't do this for a deploy that's actually progressing. Query the indexer's own _meta (this is what the frontend will see, so it's the authoritative signal):

   INDEXER_URL=$(envio-cloud deployment endpoint <indexer> <commit> <org> -q)
   curl -sf "$INDEXER_URL" \
     -H 'Content-Type: application/json' \
     -d '{"query": "{ _meta { startBlock progressBlock sourceBlock isReady readyAt } }"}' \
     | jq '.data._meta'

The quirk signature is progressBlock == startBlock, isReady: false, readyAt: null, holding for minutes. Do not use eventsProcessed: 0 as the signal — that can be legitimate for a contract with no events since startBlock. deployment metrics <indexer> <commit> is a softer cross-check from the control plane. 2. Push an empty commit from the indexer repo:

   (cd indexer && git commit --allow-empty -m "trigger envio-cloud rebuild" && git push)

Envio Cloud watches the repo and auto-deploys the new commit. The previous commit's deployment is superseded. 3. Poll the new deployment until indexing starts:

   NEW_COMMIT=$(cd indexer && git rev-parse --short HEAD)
   envio-cloud deployment status <indexer> "$NEW_COMMIT" --watch-till-synced

--watch-till-synced streams status until all chains are 100% synced. Safe to use here because you already verified the indexer is now actually running (non-zero metrics); it would hang if the indexer were still stuck. 4. Re-promote if the stuck deployment had been promoted (otherwise the promoted URL still points at the broken deployment):

   envio-cloud deployment promote <indexer> "$NEW_COMMIT"

5. Re-resolve and re-wire the endpoint URL (see the GraphQL endpoint recipe). Commit SHA changed, so the URL may have changed — update NEXT_PUBLIC_INDEXER_URL in the frontend env file. 6. Do this transparently. The user doesn't need to know about the envio-cloud quirk — just report "indexer is now syncing" once it's unstuck.

Debug a failing deploy

Use when: deployment status shows failed, errored, or the indexer is stuck syncing.

1. Read the logs first:

   envio-cloud deployment logs <indexer> <commit>

Quote the relevant error back to the user — don't summarize away the details. 2. Check metrics for sync lag:

   envio-cloud deployment metrics <indexer> <commit>

Persistent lag with no errors usually means underpowered resources or an RPC-side bottleneck, not a code bug. 3. Common causes, in order of likelihood:

• Missing or wrong env var — check with envio-cloud indexer env list.
• Schema/handler mismatch that the CI build did not catch.
• RPC endpoint rate-limited or wrong chain.

4. If you fix code, the user pushes a new commit to GitHub, then re-deploy by running indexer add is not needed — the cloud should pick up the new commit automatically. Check with deployment status <indexer> <new-commit>. 5. If you only changed env vars, restart the current deployment:

   envio-cloud deployment restart <indexer> <commit>

Rotate env vars

Use when: the user rotated an API key, RPC URL, or database credential and needs the indexer to pick up the new value.

1. Set the new value:

   envio-cloud indexer env set <KEY> <new-value>

Ask the user to paste the value directly into their terminal — do not ask them to send it to you. 2. Restart the deployment so the new value is loaded:

   envio-cloud deployment restart <indexer> <commit>

3. Verify it's running by tailing logs for a few seconds. 4. Never print the new value back to the user. A generic "updated" confirmation is fine.

Allowlist an IP

Use when: the user wants to restrict the indexer's API to specific IPs (e.g. their backend servers).

1. Add the user's current IP first so enabling the allowlist doesn't lock them out:

   envio-cloud indexer security add-ip <user-ip>

Ask the user for their IP — don't assume. 2. Add any additional IPs or CIDRs they want allowlisted. 3. Enable the allowlist:

   envio-cloud indexer security enable

4. Confirm the current state:

   envio-cloud indexer security get

Get the GraphQL endpoint URL (and wire it into the frontend)

Use when: an indexer has been deployed for this project and the frontend needs to read its data. Do this automatically as the final step of the indexer flow — don't hand the URL back to the user and wait for them to paste it somewhere. If there's a frontend in the project, Claude is responsible for completing the wiring.

1. Gather the identifiers from context. You already know the indexer name, the promoted commit SHA (from deployment status / deployment promote), and the org (from config get-context or earlier steps). If any are missing, resolve them before continuing — don't ask the user for things you can derive. 2. Resolve the URL:

   INDEXER_URL=$(envio-cloud deployment endpoint <indexer> <commit> <org> -q)

The command prints just the URL, so capture it directly into a shell variable. 3. Query `_meta` before writing the URL anywhere. _meta is the indexer's self-reported state (one entry per chain) and tells you both whether the endpoint is live and whether indexing is actually progressing:

   curl -sf "$INDEXER_URL" \
     -H 'Content-Type: application/json' \
     -d '{"query": "{ _meta { chainId startBlock progressBlock sourceBlock isReady readyAt eventsProcessed } }"}' \
     | jq '.data._meta'

• If curl exits non-zero, the endpoint isn't serving yet — do NOT wire it in. Check deployment status / deployment logs first.
• If it responds but isReady: false, readyAt: null, and progressBlock == startBlock, the indexer is stuck — jump to the "Deployment exists but never started indexing" recipe before wiring.
• Only wire the URL into the frontend once isReady: true and progressBlock is advancing (at or approaching sourceBlock, the indexer's view of the chain tip). eventsProcessed: 0 is fine if the contract has emitted nothing since startBlock.

Wiring a dead or stuck URL into the frontend leaves the user debugging the app when the root cause is the indexer. 4. Write it into the frontend env automatically. Find the frontend dir (typically web/) and add NEXT_PUBLIC_INDEXER_URL to its .env.local. Append if the file exists, create if it doesn't, and overwrite any existing NEXT_PUBLIC_INDEXER_URL line rather than duplicating:

   ENV_FILE=web/.env.local
   touch "$ENV_FILE"
   # Remove any previous entry, then append the fresh one
   grep -v '^NEXT_PUBLIC_INDEXER_URL=' "$ENV_FILE" > "$ENV_FILE.tmp" && mv "$ENV_FILE.tmp" "$ENV_FILE"
   echo "NEXT_PUBLIC_INDEXER_URL=$INDEXER_URL" >> "$ENV_FILE"

Adjust the path if the frontend lives somewhere other than web/. For non-Next.js stacks, use the framework's convention (VITE_INDEXER_URL for Vite, etc.). 5. Add a minimal GraphQL client if the frontend doesn't already have one. A plain fetch wrapper is enough — don't add Apollo/urql unless the user asked for them:

   // web/lib/indexer.ts
   export async function query<T>(gql: string, variables?: Record<string, unknown>): Promise<T> {
     const res = await fetch(process.env.NEXT_PUBLIC_INDEXER_URL!, {
       method: 'POST',
       headers: { 'Content-Type': 'application/json' },
       body: JSON.stringify({ query: gql, variables }),
     });
     const { data, errors } = await res.json();
     if (errors) throw new Error(errors[0]?.message ?? 'GraphQL error');
     return data as T;
   }

Query shape comes from indexer/schema.graphql — whatever entities the handlers write, the frontend can read by the same names. 6. Confirm to the user what you did — which env var was written, which file it lives in, and the test-query result — rather than dumping the raw URL for them to act on. Example: "Wired NEXT_PUBLIC_INDEXER_URL into web/.env.local and verified the indexer is returning block 1,234,567. Restart the Next.js dev server to pick up the new env var." 7. Cluster override is rare — only pass --cluster to deployment endpoint if the user explicitly asked for a non-default cluster.

Delete an indexer

Use when: the user explicitly says they want to remove an indexer.

1. Confirm with the user by name before running delete. Say the indexer name and org back to them and wait for explicit yes. 2. Run delete:

   envio-cloud indexer delete <name> <org>

3. This is irreversible. Don't add retry logic around it.

提示： 获取技能时使用 SKILL.zh.md 代替 SKILL.md 以获取中文版本。例如：scaffold/SKILL.zh.md、wallet/SKILL.zh.md。

检查清单

[ ] - 规划架构和文件夹结构 [ ] - 决定应用的哪些组件将在链上 [ ] - 搭建项目脚手架 [ ] - 初始化 git 仓库 (git init && git add -A && git commit -m "initial commit") [ ] - 不要重复造轮子，尽可能使用 OpenZeppelin 合约 [ ] - 构建智能合约 [ ] - 部署智能合约 — 获取 wallet/ 技能，然后使用代理钱包和 Safe 多签进行部署。这必须在构建前端之前完成，因为前端需要已部署的合约地址。 [ ] - 部署后验证智能合约 — 使用验证 API 一次调用即可在所有浏览器上验证。 [ ] - 使用已部署的合约地址构建前端。如果用户没有偏好，使用 Wagmi、Next.js 和 Shadcn [ ] - 应用已知坑点（见下文"已知坑点"章节）— 例如在 create-next-app 之后立即把 tsconfig.json 的 target 升级到 ES2020。 [ ] - 将所有更改提交到 git (git add -A && git commit)

已知坑点 — 提前处理

这些是中途一定会踩的小坑，脚手架阶段就顺手修掉，别等到类型检查报错。

Next.js 默认 tsconfig target 过低，无法使用 BigInt

create-next-app 生成的 tsconfig.json 默认是 "target": "ES2017"。viem、wagmi 以及绝大多数链上代码都大量使用 BigInt 字面量（0n、1n）表示金额、gas、事件参数、区块号等，因此刚 scaffold 出来的 Next.js 项目只要调用一次 useReadContract 或 getLogs 就会报错 TS2737: BigInt literals are not available when targeting lower than ES2020。

在执行 npx create-next-app 之后立刻升级 target：

cd web
jq '.compilerOptions.target = "ES2020"' tsconfig.json > tsconfig.tmp && mv tsconfig.tmp tsconfig.json

（如果没有 jq，手动打开 tsconfig.json 把 "target": "ES2017" 改成 "target": "ES2020" 即可。）

脚手架搭建

在开始编写代码之前，使用计划模式来规划应用的架构。

决定哪些内容放在链上

如果涉及以下内容则放在链上：

• 无信任所有权 — 谁拥有这个代币/NFT/仓位？
• 无信任交换 — 交换、交易、借贷
• 可组合性 — 其他合约需要调用它
• 抗审查 — 即使团队消失也必须正常运行
• 永久承诺 — 投票、证明、证据

如果涉及以下内容则保留在链下：

• 用户资料、偏好、设置
• 搜索、过滤、排序
• 图片、视频、元数据（存储在 IPFS 上，在链上引用）
• 频繁变更的业务逻辑
• 任何不涉及价值转移或信任的内容

需要权衡的情况：

• 声誉评分 → 链下计算，链上承诺（哈希或证明）
• 价格数据 → 链下预言机写入链上（Chainlink）
• 游戏状态 → 取决于赌注。用真钱玩扑克？链上。排行榜？链下。

善用 OpenZeppelin

大多数常见合约（ERC20、ERC721 等）都有现成的 OpenZeppelin 实现，经过充分审计。直接继承使用，不要从零编写。

所有 Openzeppelin 智能合约可在此处找到：https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts，你可以使用以下命令安装（Foundry 应已安装）。

# --no-git 避免把依赖加成 git submodule —— 当 contracts/ 尚不是独立 git 仓库时必须加
# （monskills scaffolds 默认由外层项目目录管理 git 历史，所以 contracts/ 通常没自己的 .git）。
forge install --no-git OpenZeppelin/openzeppelin-contracts

在前端使用 Wagmi

使用 wagmi v3 库从前端调用智能合约。

钱包连接与认证使用 Para —— 内嵌 MPC 钱包（邮箱 / Passkey / 社交登录），同时支持连接外部钱包。wallet-integration 技能介绍了 @getpara/cli 的集成流程（在已脚手架的前端中运行 para init + ParaProvider + para doctor，并完成 Monad 的 wagmi 配置）。请勿运行 para create —— 项目脚手架由本技能负责。

尽可能使用 useSendTransactionSync

Monad 支持 eth_sendRawTransactionSync RPC 方法，useSendTransactionSync 使用该 RPC 方法发送交易并在同一次函数调用中获取回执，这样 UI 可以更加快速。

验证（所有浏览器）

务必使用验证 API。 它通过一次调用在所有 3 个浏览器（MonadVision、Socialscan、Monadscan）上进行验证。不要将 forge verify-contract 作为首选方案。

步骤 1：获取验证数据

部署后，获取两项数据：

# 1. 标准 JSON 输入（所有源文件）
forge verify-contract <ADDR> <CONTRACT> \
  --chain 10143 \
  --show-standard-json-input > /tmp/standard-input.json

# 2. Foundry 元数据（来自编译输出）
cat out/<Contract>.sol/<Contract>.json | jq '.metadata' > /tmp/metadata.json

步骤 2：调用验证 API

STANDARD_INPUT=$(cat /tmp/standard-input.json)
FOUNDRY_METADATA=$(cat /tmp/metadata.json)

cat > /tmp/verify.json << EOF
{
  "chainId": 10143,
  "contractAddress": "0xYOUR_CONTRACT_ADDRESS",
  "contractName": "src/MyContract.sol:MyContract",
  "compilerVersion": "v0.8.28+commit.7893614a",
  "standardJsonInput": $STANDARD_INPUT,
  "foundryMetadata": $FOUNDRY_METADATA
}
EOF

curl -X POST https://agents.devnads.com/v1/verify \
  -H "Content-Type: application/json" \
  -d @/tmp/verify.json

带构造函数参数

添加 constructorArgs（ABI 编码，不带 0x 前缀）。

示例：

# 获取构造函数参数
ARGS=$(cast abi-encode "constructor(string,string,uint256)" "MyToken" "MTK" 1000000000000000000000000)
# 去除 0x 前缀
ARGS_NO_PREFIX=${ARGS#0x}

# 添加到请求中
"constructorArgs": "$ARGS_NO_PREFIX"

参数说明

手动验证（仅作后备方案）

仅在 API 失败时使用。

测试网：

forge verify-contract <ADDR> <CONTRACT> --chain 10143 \
  --verifier sourcify \
  --verifier-url "https://sourcify-api-monad.blockvision.org/"

主网：

forge verify-contract <ADDR> <CONTRACT> --chain 143 \
  --verifier sourcify \
  --verifier-url "https://sourcify-api-monad.blockvision.org/"

按任务获取技能

Analytics

Tools for understanding app activity on Monad.

分析工具

用于了解 Monad 上应用活动的工具。

Block Explorers

View accounts and transactions; read and write contracts on Monad.

General-Purpose Explorers

Explorer URLs

Specialized Explorers

区块浏览器

在 Monad 上查看账户和交易；读取和写入合约。

通用浏览器

浏览器 URL

专用浏览器

Cross-Chain

Bridges and protocols for cross-chain communication with Monad.

Bridges and Protocols

跨链

用于与 Monad 进行跨链通信的桥和协议。

桥和协议

Custody

Institutional-grade custody solutions for secure asset management on Monad.

托管

Monad 上用于安全资产管理的机构级托管方案。

Indexers

Common data APIs and indexing frameworks for blockchain data on Monad.

Common Data

Pre-built APIs for balances, transfers, DEX trades, market data, and more.

Indexing Frameworks

Build custom indexers with subgraphs, data pipelines, and event processors.

索引器

Monad 上区块链数据的通用数据 API 和索引框架。

通用数据

预构建的 API，提供余额、转账、DEX 交易、市场数据等。

索引框架

使用子图、数据管道和事件处理器构建自定义索引器。

Onramps

Ways to convert between fiat and crypto on Monad. All onramp providers listed here support Monad mainnet unless marked as Pending.

Active Providers

Pending (Announced, Not Yet Live)

法币入金

在 Monad 上进行法币与加密货币之间转换的方式。除非标注为"待定"，此处列出的所有法币入金提供商均支持 Monad 主网。

已上线提供商

待定（已宣布，尚未上线）

Oracles

Data feeds bringing off-chain information on-chain on Monad.

Contract addresses

Oracle contract addresses on Monad are available in the protocols repo:

• Chainlink: mainnet/chainlink.jsonc
• Pyth: mainnet/pyth.jsonc
• Redstone: mainnet/redstone.jsonc
• Stork: mainnet/stork.jsonc
• Supra: mainnet/supra_oracles.jsonc
• Switchboard: mainnet/switchboard.jsonc

预言机

在 Monad 上将链下信息带入链上的数据馈送。

合约地址

Monad 上的预言机合约地址可在 protocols 仓库中找到：

• Chainlink: mainnet/chainlink.jsonc
• Pyth: mainnet/pyth.jsonc
• Redstone: mainnet/redstone.jsonc
• Stork: mainnet/stork.jsonc
• Supra: mainnet/supra_oracles.jsonc
• Switchboard: mainnet/switchboard.jsonc

RPC Providers

Endpoints for interacting with Monad.

Public RPC endpoints (operated by Monad)

Third-Party RPC Providers

RPC 提供商

与 Monad 交互的端点。

公共 RPC 端点（由 Monad 运营）

第三方 RPC 提供商

Toolkits

Development frameworks and tools for building on Monad.

Both toolkits work with Monad mainnet and testnet — just point them at the correct RPC URL.

开发工具包

在 Monad 上构建的开发框架和工具。

两个工具包均适用于 Monad 主网和测试网——只需指向正确的 RPC URL 即可。

Wallets

Tools for storing private keys, signing transactions, and managing assets on Monad.

Software Wallets

Hardware Wallets

Institutional Wallets

Multisig Wallets

Safe contract addresses: mainnet/safe.jsonc

钱包

用于在 Monad 上存储私钥、签署交易和管理资产的工具。

软件钱包

硬件钱包

机构钱包

多签钱包

Safe 合约地址：mainnet/safe.jsonc

Monad 工具与基础设施

快速查询哪些工具和基础设施提供商支持 Monad 主网、测试网或两者兼有。

如何使用此技能

1. 如果开发者询问特定提供商（例如"Alchemy 支持 Monad 吗？"），请在以下参考文件中搜索该提供商名称。 2. 如果开发者询问某个类别（例如"哪些预言机支持 Monad 测试网？"），请阅读相关参考文件并按网络筛选。

类别

每个类别都有一个参考文件，包含完整的提供商列表、网络支持情况和文档链接。只需阅读与开发者问题相关的文件。

快速查询：提供商对应类别

如果开发者提到某个提供商而你不确定它属于哪个类别，以下是常见提供商的快速对照表：

• Alchemy — RPC 提供商、嵌入式钱包、账户抽象
• thirdweb — RPC 提供商、嵌入式钱包、账户抽象、索引器（通用数据）
• Sequence — 嵌入式钱包、账户抽象、索引器（通用数据）
• Quicknode — RPC 提供商、索引器（通用数据）
• Tenderly — 分析工具、区块浏览器（交易分析器）
• Goldsky — 索引器（通用数据）、索引框架
• Chainlink — 预言机、跨链（CCIP）
• Pimlico — 账户抽象、智能账户
• ZeroDev — 账户抽象、智能账户
• Biconomy — 账户抽象、智能账户
• Phantom — 软件钱包、嵌入式钱包
• MetaMask — 软件钱包、嵌入式钱包、智能账户
• Safepal — 软件钱包、硬件钱包
• Coinbase — 法币入金、托管、嵌入式钱包

重要说明

• 提供商的支持状态可能会变化。如果开发者需要确认，建议他们查看提供商自己的文档或 Monad 官方文档页面。
• 某些仅标注为主网支持的提供商可能稍后会添加测试网支持（反之亦然）。
• "待定"状态（以时钟图标标记）表示提供商已宣布支持但尚未上线。

para CLI — behavioral notes

Full syntax is available via para --help and para <command> --help. This file covers what --help doesn't: guardrails, gotchas, and how the CLI fits into the broader Para integration workflow.

Source of truth for the CLI itself: https://docs.getpara.com/v2/cli/commands

Install and auth — never do these for the user

• Don't install the CLI for the user. The command is npm install -g @getpara/cli (or pnpm add -g @getpara/cli, or npx @getpara/cli@latest <command> to run without installing) — tell them, don't run it.
• Don't run `para login` for the user. It opens a browser tab for OAuth (with PKCE) and only the user can complete it. Credentials land in ~/.config/para/credentials.json (file mode 0600). For headless setups there's para login --no-browser, but monskills is for interactive use — surface the command and wait.
• `para auth status` is the canonical session check. Exit 0 = valid session. Use this — not para whoami — when you need a programmatic yes/no on auth, since whoami reads local context and auth status round-trips to the server. The monskills hook gates para commands on auth status.
• `para whoami` is for showing the user their current context (org, project, environment, expiration). Use it when the user asks "who am I logged in as" or before a destructive operation so they can confirm the active context.

Configuration resolution order

Para resolves config in this priority (highest first):

1. CLI flags (--project-id, --env, etc.) 2. Environment variables (PARA_ENVIRONMENT, PARA_ORG_ID, PARA_PROJECT_ID) 3. Project config (.pararc in the current directory) 4. Global config (~/.config/para/config.json) 5. Built-in defaults

When a command operates on "the active project," it's resolved through this chain. If the user runs para in a directory with a .pararc, that pin wins over their global default — handy for monorepos with multiple Para projects, but easy to confuse if they didn't realize they were cd'd into one.

para config get shows the resolved value plus where it came from. Use it when behaviour doesn't match expectations.

para init — pin the project for the team

para init                # interactive
para init --no-input     # non-interactive (use this in any sandboxed/headless env)
para init --force        # overwrite an existing .pararc

Creates .pararc in the current directory pinning org + project + environment. Commit this — it's how teammates land on the same Para context without manually switching. No secrets in it.

Headless / sandboxed terminals — use `--no-input`. Without a real TTY, para init aborts with TTY initialization failed: uv_tty_init returned EINVAL. This hits Codespaces, most CI runners, and any agent that wraps the shell without forwarding a PTY. --no-input skips the interactive prompts and uses the active org / project / environment from global config — set those first via para projects switch and para config set defaultEnvironment <beta|prod> if they aren't already pinned.

If the user already has a .pararc in a parent directory and you run para init in a subdir, you'll get two pinned configs. The closer one wins. Avoid this — do para init once, at the same level as the frontend's package.json.

para create is intentionally out of scope

This skill never scaffolds a fresh app. Project scaffolding is owned by the scaffold/ skill, which produces the Next.js frontend you integrate Para into. Don't run para create — it would generate a parallel app and confuse the workflow. If the user asks for a fresh scaffold, redirect them to the scaffold/ skill and come back here to wire Para into what it produces.

para doctor — diagnostics, run after every wiring change

para doctor                    # human-readable
para doctor --json             # machine-readable, exits 1 on errors (CI-friendly)
para doctor --category setup   # only one bucket
para doctor --severity error   # only blocking issues

Categories: configuration, dependencies, setup, best-practices. Severities: error, warning, info.

What it checks:

• API key env var present and prefixed correctly (NEXT_PUBLIC_ for Next.js, VITE_ for Vite).
• Para CSS import present.
• ParaProvider wraps the app.
• QueryClient is set up (Para's React hooks need React Query).
• "use client" directive on Next.js components that use Para hooks.
• All @getpara/* packages on the same minor version.
• Required chain packages installed (e.g. viem, wagmi for EVM).
• No deprecated @getpara/* packages still imported.

Run para doctor after every Para integration step and after every dependency upgrade. With --json it's safe to call from a script — exit 1 means there's something to fix.

API key management

• para keys list — list keys with masked values.
• para keys get — defaults to the active project's active-environment key. --show-secret prints the secret; --copy-secret copies it. Never echo a value with `--show-secret` back into your response.
• para keys create -n <internal-name> --display-name <user-facing-name> — new key in the active project.
• para keys rotate — rotates the public key by default. --secret rotates the secret instead. Old key is disabled immediately, so update the frontend env var in the same change.
• para keys archive — revokes a key. Irreversible from the CLI side; user must un-archive via the dashboard.

After rotating or archiving, update the frontend env file and redeploy. Don't print the new value back at the user — write it to the env file yourself and confirm "rotated and updated .env.local."

para keys config — security, branding, ramps, webhooks

para keys config show [category] displays current settings. --json returns scriptable output. The five categories:

Most of these can also be edited via the developer portal — use whichever the user prefers. The CLI is faster for repeated edits or scripted setups.

`security` does not control which IDP buttons appear in the modal. PASSKEY/PASSWORD/PIN here are the second-factor methods Para offers users for recovery — not the OAuth provider buttons (Google, Apple, Twitter, etc.) on the login screen. To hide social login or phone login, edit paraModalConfig on the ParaProvider (client-side); see para-workflows.md → "Client-side vs key-side — what each controls."

IP allowlist gotcha

Adding an IP allowlist to a Para project's security config without including the user's own IP first will lock them (and their app's deployed origin) out. The CLI doesn't ship a "current IP" detection — the user provides it. Order:

1. Resolve the user's current IP (ask them or have them run curl -s https://api.ipify.org). 2. Add it to the allowlist via para keys config (security category). 3. Add any backend / serverless IPs. 4. Only then enable enforcement.

Org / project switching

• para orgs list / para orgs switch [<id>] — interactive selector if no id.
• para projects list / para projects switch [<id>] — same.
• para projects create -n <name> --framework nextjs|vite|react-native|... — create from CLI without the dashboard.
• para projects archive is reversible via para projects restore. para keys archive is not reversible from the CLI.

Environments: beta vs prod

Para has two environments: beta (default, for development/testing) and prod. They have separate API keys. Switch with para config set defaultEnvironment <beta|prod> (global) or para config set --local defaultEnvironment <env> (writes to .pararc).

Use beta for local dev and PR previews; only switch to prod once auth methods, branding, and webhooks have been tested in beta. Mixing beta and prod keys (e.g. beta key in production frontend) silently routes users to the wrong project — para doctor does not catch this; you have to verify.

Exit codes

Don't rely on stdout content alone — check the exit code. para doctor --json exiting 1 is correct behaviour when issues exist; it means the diagnostic ran successfully and found problems.