ECPIP-1: Quote-posts

[davidfurlong]

ECPIP-1: Standardizing Quote-Posts Using CAIP-373

Abstract

This ECPIP introduces a protocol-agnostic mechanism for quote-posts in the Ethereum Comments Protocol (ECP). While several clients—such as Paper and Interface—already support quote postings independently, there is no unified method across the ecosystem. This proposal adopts CAIP-373: EVM Smart Contract Call Reference Specification as the universal identifier for quoted comments, ensuring interoperability, cross-chain compatibility, and alignment with existing tooling.

---

Motivation

ECP enables lightweight, decentralized commenting via on-chain storage. Quote-posting remains a key social primitive with no standard implementation. Divergence across clients (e.g., Paper by @kualta and Interface by @palevoo) leads to poor interoperability and fragmentation. This proposal ensures:

1. Quote-posts may reference multiple comments.
2. References remain valid across chains and protocol versions.
3. Identifiers align with CAIP standards and existing blockchain tools.
4. Clients render quote-posts flexibly while relying on a unified identifier format.

---

Specification

Representation of Quote-Posts

• Comment Type: Quote-posts remain commentType = 0 (regular posts).
• Content Field:
  • The content field embeds both the post text and one or more CAIP-373 references to the quoted comments.
  • Each reference MUST conform to CAIP-373.
• Client Behavior:
  • Clients MUST parse content for embedded CAIP-373 references.
  • Each CAIP-373 reference is resolved on-chain to retrieve the quoted comment using the included ABI-encoded function call.

Normative Constraints

• No block numbers: Implementations MUST NOT include a :block_number segment in the CAIP-373 references used for ECP quote-posts. Resolution is always against the latest state.

---

Example

A quote-post referencing the real comment ID
0x6bbab7fa5d988676b01e9b5b72913319de5b835063fa8751ea1155078de81034:

    {
      "commentType": 0,
      "content": "Key insight:\n\neip155:8453:0xb262C9278fBcac384Ef59Fc49E24d800152E19b1:call:0x8c20d5876bbab7fa5d988676b01e9b5b72913319de5b835063fa8751ea1155078de81034"
    }

• eip155:8453 identifies the Base chain.
• 0xb262C9278fBcac384Ef59Fc49E24d800152E19b1 is the ECP CommentManager contract.
• call:0x8c20d587…81034 represents the ABI-encoded function selector + argument(s) to fetch that specific comment ID.

To generate the ABI-encoded function selector, you can use the code below

import { encodeFunctionData } from 'viem'
import { CommentManagerABI } from '@ecp.eth/sdk/abis'

const commentId =
  '0x6bbab7fa5d988676b01e9b5b72913319de5b835063fa8751ea1155078de81034'

const calldata = encodeFunctionData({
  abi: CommentManagerABI,
  functionName: 'getComment',
  args: [commentId],
})

console.log(calldata)
// -> 0x8c20d5876bbab7fa5d988676b01e9b5b72913319de5b835063fa8751ea1155078de81034

Multiple quoted comments are allowed by including multiple CAIP-373 references within the content body (e.g., separated by lines or spaces).

---

Advantages of CAIP-373

• Cross-chain resilience: Works across Base, Ethereum L2s, and future ECP deployments.
• Protocol longevity: Remains valid across future ECP versions if the read interface is preserved.
• Tooling alignment: Compatible with standard ABI encoding and CAIP parsers.
• Multi-quote support: Natively supports quoting several comments in one post.
• Simplicity: No historical block-number semantics to implement or validate.

---

Implementation Guidelines

1. Indexers should parse CAIP-373 identifiers from content and resolve them to fetch the referenced comments.
2. Clients should implement a lightweight parser to extract and render quoted comments inline.
3. Graceful degradation: Clients that don’t support CAIP-373 simply ignore the identifiers and render only the textual content.

---

Backwards Compatibility

• Existing posts remain unaffected.
• Clients without CAIP-373 support continue to function.
• Indexers/clients may adopt parsing incrementally without disruption.

---

Alternatives Considered

• Solution A – New commentType = 2 with parentId
  • Limitation: single quote; not inherently cross-chain.
• Solution C – New commentType = 2 with content-embedded references
  • Limitation: unenforceable on-chain without a protocol upgrade.
• Solution B – Regular posts (commentType = 0) with content-embedded references
  • Preferred: no protocol changes, supports multiple quotes.

This ECPIP refines Solution B by standardizing on CAIP-373 for the reference format.

---

Original Evaluation (Preserved)

There is currently no standardized way to do Quote-posts on ECP, but there is already one client (paper, shoutout @kualta) that supports quote posts and another (Interface, shoutout @palevoo) that is interested in supporting them, so it makes sense to agree on the best way to support them.

Considerations:

1. Any new constraints can't be enforced at the protocol level without releasing a new protocol version
2. App-agnostic identifiers are more desirable for interoperability, and there's no standardised way to reference a comment on ECP
3. It should be possible to quote-post multiple ECP posts in one comment at the protocol level, and let clients decide how to render or enforce their own constraints on top of that
4. It should be possible to quote-post across ECP versions in the future, including across deployments on different chains
5. Any identifier should ideally contain all the necessary information for an app to lookup the comment from the blockchain without any additional information

Possible solutions (as originally discussed in the ECP community telegram):
A. Quote-posts as a new commentType, for example commentType=2 with the content being used for the post contents and the parentId being set the post that is being quoted
B. Quote-posts as posts (commentType=0), that mention the quoted-posts in the content by some app-agnostic universal identifier for the comment.
C. Quote-posts as a new comment Type (for example commentType=2), that mention the quoted-posts in the content by some app-agnostic universal identifier for the comment.

Solution A has the notable problem that it only allows quoting one comment, and that it doesn't work across possible future ECP deployments across chains or versions.

Solution C has the problem that the inclusion of at least one quoted post in the contents can't be enforced onchain without a new ECP version release, so it's unreliable onchain at best and needs to be resolved at the indexer level.

Solution B seems to not have any significant downsides, but the question remains what the standardised identifier for a comment should be. A CAIP would be ideal, but since comments in ECP are stored in a mapping and are not NFTs, there isn't a current CAIP as far as I can tell that could be used to uniquely identify a comment.

There's a couple of options for a standardized identifier
B1) Extend a combination of CAIP-2 and CAIP-10 with a non-standard suffix, for example
eip155:8453:0xb262C9278fBcac384Ef59Fc49E24d800152E19b1#commentId=0x..., or corresponding to the mapping name comments in the contract: eip155:8453:0xb262C9278fBcac384Ef59Fc49E24d800152E19b1#comments=0x...
B2) We could define a new privileged namespace convention for ECP comments, similar to the way IPFS links have their own, for example ECP://eip155:8453/0xb262C9278fBcac384Ef59Fc49E24d800152E19b1/comments/0x... (corresponding to ECP://<caip-2 chainid>/<contract address>/<the mapping name, for now only comments is supported>/<comment id>)
B3) Referencing the transaction hash of the comment will likely not work, due to a transaction being able to create multiple comments

Ask: Would love to hear thoughts and ideas, in particular alternatives to the standardised identifier, any relevant CAIP discussions and perhaps inspiration from how other protocols have solved this problem

[kualta]

thanks for writing it up @davidfurlong! can you elaborate more on why we need to use non-standard suffix specifically for B1? since in CAIP-10 links use colon symbol : to go from more general -> to more specific wouldn't it make sense to use eip155:chain_id:commentmanager_address:hex_ecp_comment_id? does the spec disallow this use?

[davidfurlong]

CAIP-10 is specifically for accounts and doesn't support a fourth component to it. It strictly supports

account_id:        chain_id + ":" + account_address
chain_id:          [-a-z0-9]{3,8}:[-_a-zA-Z0-9]{1,32} (See [CAIP-2][])
account_address:   [-.%a-zA-Z0-9]{1,128}

for example here's their JS library implementation: https://github.com/ChainAgnostic/caip-js/blob/806cb9eb4c1609c65231d278326e2a134b37df66/src/spec.ts#L21

Any extension is not per spec and won't work with libraries etc

[stephancill]

I am in favour of option B

As a sidenote if there is a CAIP standard for linking to a read method on a contract i might favour linking to eip155:chain_id:commentmanager_address:getComment_function_selector:hex_ecp_comment_id (noting the : suffix suggestion by @kualta)

e.g. a quote of comment 0x023b94066ab9b8111a134e02e2f579d4a8a2bc39fcf64e6dcb00002ae0404208 would be

eip155:8453:0xb262C9278fBcac384Ef59Fc49E24d800152E19b1:0x8c20d587:0x023b94066ab9b8111a134e02e2f579d4a8a2bc39fcf64e6dcb00002ae0404208

Not sure how sensitive we are to the content length here. Might be worth standardizing a shorthand for efficiency?

[davidfurlong]

I like it. I'm guessing this spec should be narrowed to only be used for read only EVM functions?

[bumblefudge]

nah just write a generic one and an eth profile that says "put the actual call" and mentions so far only "function" is call

[davidfurlong]

I drafted a CAIP on a branch (before creating an actual CAIP draft/PR), lmk if you have any feedback @stephancill, I added you as an author

ChainAgnostic/CAIPs@b419853

[TimDaub]

ChainAgnostic/CAIPs#87 (comment)

Depending on the smart contract logic some of these identifiers could have their underlying data object change over time. However if the block number was included the IDs could be cached indefinitely as they‘d be immutable.

Maybe not what you‘re looking for but I thought I bring it up since I had worked on smth similar before

[stephancill]

@davidfurlong thanks for drafting, it looks good to me!

@TimDaub thanks for calling this out, I think it's worth considering adding it to the spec, perhaps as an optional suffix:

namespace:chainid:contract:call:data:optional_blocknumber

[davidfurlong]

Alright thanks everyone for the feedback! A draft CAIP PR is open here: ChainAgnostic/CAIPs#373

[normanzb]

the ABI-encoded function selector + argument(s) to fetch that specific comment

@davidfurlong in the example, would you mind clarify the details of what function selector and arguments are used to generate 0x8c20d587…81034

[davidfurlong]

that hex is just the ABI-encoded call to getComment(bytes32).
Function selector: 0x8c20d587 ⇒ keccak256("getComment(bytes32)")[:4].

import { encodeFunctionData } from 'viem'
import { CommentManagerABI } from '@ecp.eth/sdk/abis'

const commentId =
  '0x6bbab7fa5d988676b01e9b5b72913319de5b835063fa8751ea1155078de81034'

const calldata = encodeFunctionData({
  abi: CommentManagerABI,
  functionName: 'getComment',
  args: [commentId],
})

console.log(calldata)
// -> 0x8c20d5876bbab7fa5d988676b01e9b5b72913319de5b835063fa8751ea1155078de81034