Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughAdds a new Morph Rails documentation section with nine pages covering architecture, Infra (AltFee, Reference Key), Middleware (Private Transactions), and Agentic Payment (x402, Skills, CLI, MCP), and updates Docusaurus navbar and sidebar to expose the new content. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Server as Resource Server
participant Facilitator
participant Sequencer
participant Chain as On-chain
Client->>Server: GET /paid-resource
Server-->>Client: 402 + X-Payment- headers (network, addr, amount, token)
Client->>Facilitator: Construct & sign x402 payment (includes Reference Key)
Facilitator->>Sequencer: Submit AltFee Tx (token-paid gas)
Sequencer->>Chain: Execute tx, emit settlement proof
Sequencer-->>Facilitator: Settlement proof / tx receipt
Client->>Server: Retry with X-Payment-Proof header
Server->>Facilitator: Verify proof / validate receipt
Facilitator-->>Server: Validation result
Server-->>Client: 200 OK (resource)
sequenceDiagram
participant MerchantApp
participant CLI/Agent
participant MorphAPI
participant Sequencer
participant Chain
MerchantApp->>CLI/Agent: Create payment request (with Reference Key)
CLI/Agent->>MorphAPI: Submit signed tx (AltFee token selected)
MorphAPI->>Sequencer: Relay AltFee Tx
Sequencer->>Chain: Execute & confirm
Chain-->>Sequencer: Confirmation
Sequencer-->>MorphAPI: Tx receipt + Reference Key mapping
MorphAPI-->>MerchantApp: Reconciliation data / transaction history
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
docs/morph-rails/infra-solutions/2-reference-key.md (1)
8-10: Avoid hard-coded launch month in availability notice.Using a fixed month/year here is likely to age quickly. Prefer timeline wording that remains accurate if launch scheduling changes.
Suggested wording update
-:::info -Reference Key will be available after the mainnet launch in April 2026. -::: +:::info +Reference Key will be available after mainnet launch. +:::🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/morph-rails/infra-solutions/2-reference-key.md` around lines 8 - 10, Replace the hard-coded availability sentence "Reference Key will be available after the mainnet launch in April 2026." with a timeline-neutral phrase (e.g., "Reference Key will be available after mainnet launch" or "Reference Key will be available following mainnet launch") so the note remains accurate if launch timing changes; update the content in docs/morph-rails/infra-solutions/2-reference-key.md by locating the exact string and substituting the neutral wording while preserving the surrounding :::info block formatting.docs/morph-rails/agentic-payment/3-morph-rails-cli.md (1)
21-23: Clarify key/material handling for a “stateless” CLI.Line 57 says the CLI is stateless, but Line 21 introduces wallet creation. Add one sentence clarifying where keys are stored (or that an external signer is required) so automation users don’t assume unsafe defaults.
Suggested doc tweak
- **Stateless** — No persistent sessions. Every command is self-contained. Agents don't need to manage connection state. + - **Stateless** — No persistent sessions. Every command is self-contained. Agents don't need to manage connection state. + Wallet key material is never kept in process memory between commands; use secure local keystore or external signer/HSM.Also applies to: 57-59
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/morph-rails/agentic-payment/3-morph-rails-cli.md` around lines 21 - 23, Clarify the "stateless" claim by updating the docs around the wallet commands (morph-cli wallet create and morph-cli wallet balance) and the "stateless" statement (lines referencing 57-59) to add one concise sentence that specifies where private keys are kept or that the CLI requires an external signer/keystore for key management; explicitly state that the CLI does not persist keys by default (or conversely where it stores them) so automation users won't assume unsafe defaults and know to supply an external signer or secure key storage.docs/morph-rails/agentic-payment/1-x402-facilitator.md (1)
16-20: Consider migrating to non-prefixed header names per RFC 6648.RFC 6648 deprecates the
X-prefix for new HTTP headers, as it causes namespace collisions when experimental headers become standardized. Use descriptive names without the prefix (Payment-Network,Payment-Address,Payment-Amount,Payment-Token) and maintainX-variants only for backward compatibility if needed. Consider registering new headers in the IANA HTTP Field Name Registry.Also applies to: 66-69, 73
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/morph-rails/agentic-payment/1-x402-facilitator.md` around lines 16 - 20, The HTTP headers use deprecated X- prefixes; change the header names from X-Payment-Network, X-Payment-Address, X-Payment-Amount, and X-Payment-Token to non-prefixed names Payment-Network, Payment-Address, Payment-Amount, and Payment-Token (keep X- variants only if you need backward compatibility), update any documentation references in this file to the new names, and consider noting registration with the IANA HTTP Field Name Registry as suggested; ensure examples and any mentions on lines referenced (including the other occurrences around the file) are updated consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/morph-rails/0-overview.md`:
- Line 57: Replace the hard, absolute marketing claims in the copy—specifically
the phrases "A wallet address is your merchant identity" and "Accept payments
from $0.001 to $1,000,000 through the same flow"—with qualified language (e.g.,
"can serve as," "for example," or "may allow") and add a parenthetical or
footnote linking to a source or benchmark methodology that supports the example
ranges; update the two occurrences flagged in the document to use conditional
phrasing ("can", "may", "for example") and include or reference a citation to
justify the example pricing/onboarding claim.
In `@docs/morph-rails/agentic-payment/4-mcp.md`:
- Around line 76-78: Update the absolute security claim in the "Runtime-managed
auth" bullet: replace the phrase "This prevents key leakage" in the bullet that
begins "Runtime-managed auth — Wallet keys and signing are handled by the MCP
server, not by the agent's prompt context." with a softened statement such as
"This reduces key exposure risk" (or equivalent cautious wording) so the doc no
longer asserts an absolute guarantee.
In `@docs/morph-rails/infra-solutions/1-altfee.md`:
- Around line 24-28: Clarify the USDC token_id semantics by explicitly stating
whether USDC requires a token_id, uses a reserved default, or should omit the
field in transactions: update the table row for USDC (token symbol "USDC" and
contract `0xe34c91815d7fc18A9e2148bcD4241d0a5848b693`) to show the canonical
value (e.g., "omitted", "0", or "N/A (use omitted-field)") and add one short
sentence below the table describing how integrators should populate the
transaction payload when sending USDC (e.g., omit token_id entirely or set
token_id to 0), referencing the term token_id so readers know exactly which
field to use.
---
Nitpick comments:
In `@docs/morph-rails/agentic-payment/1-x402-facilitator.md`:
- Around line 16-20: The HTTP headers use deprecated X- prefixes; change the
header names from X-Payment-Network, X-Payment-Address, X-Payment-Amount, and
X-Payment-Token to non-prefixed names Payment-Network, Payment-Address,
Payment-Amount, and Payment-Token (keep X- variants only if you need backward
compatibility), update any documentation references in this file to the new
names, and consider noting registration with the IANA HTTP Field Name Registry
as suggested; ensure examples and any mentions on lines referenced (including
the other occurrences around the file) are updated consistently.
In `@docs/morph-rails/agentic-payment/3-morph-rails-cli.md`:
- Around line 21-23: Clarify the "stateless" claim by updating the docs around
the wallet commands (morph-cli wallet create and morph-cli wallet balance) and
the "stateless" statement (lines referencing 57-59) to add one concise sentence
that specifies where private keys are kept or that the CLI requires an external
signer/keystore for key management; explicitly state that the CLI does not
persist keys by default (or conversely where it stores them) so automation users
won't assume unsafe defaults and know to supply an external signer or secure key
storage.
In `@docs/morph-rails/infra-solutions/2-reference-key.md`:
- Around line 8-10: Replace the hard-coded availability sentence "Reference Key
will be available after the mainnet launch in April 2026." with a
timeline-neutral phrase (e.g., "Reference Key will be available after mainnet
launch" or "Reference Key will be available following mainnet launch") so the
note remains accurate if launch timing changes; update the content in
docs/morph-rails/infra-solutions/2-reference-key.md by locating the exact string
and substituting the neutral wording while preserving the surrounding :::info
block formatting.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 7a3bbdf9-fc2f-4843-95bd-8b2fe75d7b0b
📒 Files selected for processing (11)
docs/morph-rails/0-overview.mddocs/morph-rails/agentic-payment/0-overview.mddocs/morph-rails/agentic-payment/1-x402-facilitator.mddocs/morph-rails/agentic-payment/2-morph-skill.mddocs/morph-rails/agentic-payment/3-morph-rails-cli.mddocs/morph-rails/agentic-payment/4-mcp.mddocs/morph-rails/infra-solutions/1-altfee.mddocs/morph-rails/infra-solutions/2-reference-key.mddocs/morph-rails/middleware-service/1-private-transactions.mddocusaurus.config.jssidebars.js
|
|
||
| ### SMBs & Independent Developers | ||
|
|
||
| Traditional payment providers impose onboarding thresholds that exclude small businesses — monthly volume requirements, minimum ticket sizes, lengthy KYC processes. Morph Rails has none of these. A wallet address is your merchant identity. Integrate in 5 minutes. Accept payments from $0.001 to $1,000,000 through the same flow. |
There was a problem hiding this comment.
Replace absolute market/pricing claims with qualified, sourced wording.
Line 57 and Line 69 make hard, time-sensitive claims that may be inaccurate across regions/plans and could create legal/compliance risk in public docs. Rephrase as “example” or “can,” and link a source or benchmark methodology.
Suggested safer wording
-Traditional payment providers impose onboarding thresholds that exclude small businesses — monthly volume requirements, minimum ticket sizes, lengthy KYC processes. Morph Rails has none of these. A wallet address is your merchant identity. Integrate in 5 minutes. Accept payments from $0.001 to $1,000,000 through the same flow.
+Traditional payment providers can impose onboarding thresholds that are difficult for some small businesses — such as volume requirements, ticket-size constraints, or extended verification flows. Morph Rails is designed to reduce these barriers. In many cases, teams can integrate quickly and support a wide payment range through a unified flow.-Paid content platforms, API usage billing, in-game purchases, creator tipping, micro-SaaS — these high-frequency, low-value payment scenarios are either unprofitable or impossible on traditional rails. A $0.10 API call incurs a $0.30 Stripe fee. On Morph Rails, the same transaction costs a fraction of a cent in gas, payable in stablecoins via AltFee.
+Paid content platforms, API usage billing, in-game purchases, creator tipping, and micro-SaaS often struggle with fee efficiency on traditional rails. For low-value transactions, fixed + percentage fee models can materially impact margins. On Morph Rails, network fees are typically much lower and can be paid in stablecoins via AltFee; actual costs vary by network conditions and route.Also applies to: 69-69
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/morph-rails/0-overview.md` at line 57, Replace the hard, absolute
marketing claims in the copy—specifically the phrases "A wallet address is your
merchant identity" and "Accept payments from $0.001 to $1,000,000 through the
same flow"—with qualified language (e.g., "can serve as," "for example," or "may
allow") and add a parenthetical or footnote linking to a source or benchmark
methodology that supports the example ranges; update the two occurrences flagged
in the document to use conditional phrasing ("can", "may", "for example") and
include or reference a citation to justify the example pricing/onboarding claim.
Comment on lines
+76
to
+78
| - **Standardized discovery** — Agents don't need to know Morph-specific APIs. They discover tools via MCP. | ||
| - **Runtime-managed auth** — Wallet keys and signing are handled by the MCP server, not by the agent's prompt context. This prevents key leakage. | ||
| - **Composable** — MCP tools can be chained. An agent can check balance → swap tokens → make payment → verify receipt in a single reasoning chain. |
There was a problem hiding this comment.
Avoid absolute security guarantee language.
Line 77 states this “prevents key leakage,” which is too absolute for a security claim. Prefer “reduces key exposure risk” unless formal guarantees are documented elsewhere.
Suggested wording update
-- **Runtime-managed auth** — Wallet keys and signing are handled by the MCP server, not by the agent's prompt context. This prevents key leakage.
+- **Runtime-managed auth** — Wallet keys and signing are handled by the MCP server, not by the agent's prompt context. This reduces key exposure risk.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/morph-rails/agentic-payment/4-mcp.md` around lines 76 - 78, Update the
absolute security claim in the "Runtime-managed auth" bullet: replace the phrase
"This prevents key leakage" in the bullet that begins "Runtime-managed auth —
Wallet keys and signing are handled by the MCP server, not by the agent's prompt
context." with a softened statement such as "This reduces key exposure risk" (or
equivalent cautious wording) so the doc no longer asserts an absolute guarantee.
Comment on lines
+24
to
+28
| | Token | Contract Address | Token ID | | ||
| |-------|-----------------|----------| | ||
| | USDC | `0xe34c91815d7fc18A9e2148bcD4241d0a5848b693` | — | | ||
| | BGB | `0x389C08Bc23A7317000a1FD76c7c5B0cb0b4640b5` | 4 | | ||
|
|
There was a problem hiding this comment.
Clarify USDC token_id semantics to avoid integration errors.
Line 17 says token_id is part of the transaction, but Line 26 leaves USDC token ID undefined (—). Please explicitly document whether USDC uses a concrete ID, a reserved default, or omitted-field behavior.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/morph-rails/infra-solutions/1-altfee.md` around lines 24 - 28, Clarify
the USDC token_id semantics by explicitly stating whether USDC requires a
token_id, uses a reserved default, or should omit the field in transactions:
update the table row for USDC (token symbol "USDC" and contract
`0xe34c91815d7fc18A9e2148bcD4241d0a5848b693`) to show the canonical value (e.g.,
"omitted", "0", or "N/A (use omitted-field)") and add one short sentence below
the table describing how integrators should populate the transaction payload
when sending USDC (e.g., omit token_id entirely or set token_id to 0),
referencing the term token_id so readers know exactly which field to use.
Collaborator
There was a problem hiding this comment.
这里的token 除了USDC和BGB 是不是还有USDT？要加上USDT 吗
There was a problem hiding this comment.
@vvpink，是的，您的观察非常准确！文档中存在不一致之处：
- **Overview 部分（第13行）**明确列出了
"USDC, USDT, BGB"作为支持的代币 - 但 **Supported Tokens 表格（第24-28行）**中只有 USDC 和 BGB，缺少了 USDT
建议在表格中补充 USDT 的条目，格式如下：
| Token | Contract Address | Token ID |
|-------|-----------------|----------|
| USDC | `0xe34c91815d7fc18A9e2148bcD4241d0a5848b693` | — |
| USDT | `<USDT contract address on Morph L2>` | <token_id or —> |
| BGB | `0x389C08Bc23A7317000a1FD76c7c5B0cb0b4640b5` | 4 |请 @SpectreMercury 确认 USDT 在 Morph L2 上的合约地址和 token_id，然后将其补充进表格，以确保文档与 Overview 描述保持一致。
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit