← Comment Protocol

Comment Protocol

A Decentralized Comment Attestation, Reputation, and Moderation Protocol for the Internet

Version: 1.0 Technical Whitepaper Draft Network: Solana Storage: IPFS, with optional Filecoin/Arweave archival Identity UX: Privy embedded wallets and standard Solana wallets Token: $COMMENT

Abstract

Comment Protocol is a decentralized protocol for portable comments, public reputation, transparent moderation, and spam-resistant discussion across the internet.

The protocol is built around a core separation:

  1. Comment Attestation Protocol — a high-scale layer where every comment is a signed, content-addressed attestation stored on IPFS and committed to Solana through Merkle roots or direct records.
  2. Comment State Protocol — a higher-trust state layer where Solana stores profiles, reputation, staking, moderation, reports, rewards, disputes, and promoted comment state.

This split is the foundation of the protocol.

Not every comment should become an expensive on-chain account. Instead, every comment should be a signed attestation. Important comments, disputed comments, rewarded comments, staked comments, and moderation-sensitive comments can be promoted into full on-chain state.

This design allows Comment Protocol to support high-volume consumer commenting while preserving verifiability, user ownership, transparent moderation, and portable reputation.

1. Vision

Comment Protocol turns internet comments into an open public primitive.

Today, comments are trapped inside platforms. A user's reputation on one site does not transfer to another. Moderation is opaque. Spam is cheap. Useful discussion about the same article, token, wallet, video, proposal, transaction, or product is fragmented across private databases.

Comment Protocol creates a shared comment graph that can attach discussion to any internet or blockchain object.

A target can be:

The protocol makes comments portable, reputation composable, and moderation auditable.

The long-term goal is simple:

Comments should not belong to platforms.
Reputation should not reset across applications.
Moderation should be transparent.
Spam should be economically expensive.
Discussion should be portable.

2. Core Architecture

Comment Protocol has two primary subprotocols.

2.1 Comment Attestation Protocol

The Comment Attestation Protocol is the high-throughput layer.

It defines how a user creates a verifiable comment without requiring every comment to become a dedicated Solana account.

A comment attestation consists of:

canonical comment JSON
IPFS CID
wallet signature
target hash
comment leaf hash
Merkle inclusion proof, when batched
Solana commitment, either direct or via batch root

The attestation layer answers:

Who authored this comment?
What target is it attached to?
What content CID represents the comment?
Did the author sign it?
Was it committed to Solana?
Was it included in a valid batch?

This layer is optimized for:

Most comments should live here.

2.2 Comment State Protocol

The Comment State Protocol is the trust, reputation, and enforcement layer.

It stores state that needs public settlement on Solana:

The state layer answers:

What is this user's reputation?
Is this comment hidden, disputed, slashed, or rewarded?
Did this user stake COMMENT?
Was this report confirmed?
Was this comment promoted from a batch into full state?
Which apps or moderators took action?

This layer is optimized for:

Only important state should live here.

3. Design Principles

3.1 Every comment is signed

Every comment must be signed by the author wallet. The signature proves authorship independently of any app database.

3.2 Every comment is content-addressed

Comment bodies are stored as canonical JSON on IPFS. The CID and/or CID hash is committed to Solana.

3.3 Not every comment is an account

Normal comments should be IPFS objects committed through Merkle batches. Full Solana comment accounts are reserved for comments that need state.

3.4 Important comments can be promoted

A batched comment can be promoted into a direct CommentRecord if it becomes important for staking, reporting, rewards, moderation, governance, or disputes.

3.5 Apps control display, protocol controls shared facts

Apps may choose what to display. The protocol records shared facts such as authorship, stake, reports, moderation actions, and reputation.

3.6 Moderation is explicit, not invisible

Moderation actions should produce visible protocol state or app policy records. The protocol should avoid silent deletion or hidden enforcement.

3.7 Data availability is a protocol requirement

IPFS content must be pinned and retrievable. A comment commitment is not useful if the content disappears.

3.8 UX must feel web2-simple

Privy should allow mainstream users to post with email/social login and embedded wallets without manually acquiring SOL for normal comments.

4. Protocol Actors

4.1 User

Creates comments, votes, reports, stakes tokens, builds reputation, and optionally participates in governance.

4.2 Application

Integrates the Comment Protocol widget or SDK. Applications may sponsor comments, pin content, run batchers, apply app-specific moderation, and maintain local rankings.

4.3 Batcher

Collects signed comments, stores them on IPFS, constructs Merkle trees, and submits roots to Solana.

4.4 Indexer

Reads Solana events and accounts, resolves IPFS objects, verifies signatures and Merkle proofs, reconstructs threads, and exposes APIs.

4.5 Moderator

Reviews reports, applies app-level or protocol-level actions, and participates in transparent enforcement.

4.6 Storage Provider

Pins IPFS data and optionally mirrors important objects to Filecoin, Arweave, or other archival systems.

4.7 Governance

Controls protocol parameters, treasury spending, incentives, moderation rules, and upgrades over time.

5. Canonical Comment Standard

The canonical comment standard is one of the most important parts of the protocol. Every client must produce identical canonical payloads for equivalent comments.

5.1 Required fields

Every comment object must include:

{
  "protocol": "comment-protocol",
  "schema": "comment.v1",
  "author": "SOLANA_WALLET_PUBLIC_KEY",
  "target": {
    "type": "url",
    "id": "https://example.com/article/1"
  },
  "target_hash": "hex_encoded_sha256_hash",
  "parent": null,
  "body": "Comment text",
  "body_format": "plain_text",
  "created_at": "2026-05-31T00:00:00Z",
  "nonce": "client_unique_nonce",
  "client": "app_or_sdk_identifier",
  "signature": "base58_signature"
}

5.2 Optional fields

{
  "title": null,
  "media": [],
  "mentions": [],
  "tags": [],
  "language": "en",
  "edit_of": null,
  "reply_depth": 0,
  "app_context": {},
  "content_warning": null
}

5.3 Body format

Supported body_format values:

plain_text
markdown
limited_markdown

MVP requirement:

The MVP should support plain_text and limited_markdown only.

5.4 Size limits

Suggested MVP limits:

body max length: 4,000 characters
comment JSON max size: 16 KB
media items: 0 for MVP, optional later
mentions: max 20
tags: max 10
reply depth: app-configurable, default max 20

5.5 Signature payload

The author signs the canonical comment payload excluding the signature field.

Signature domain separator:

COMMENT_PROTOCOL_COMMENT_V1

The signed message should include:

domain separator
schema
author
target_hash
parent
body hash
created_at
nonce
client

This prevents signatures from being reused in other contexts.

5.6 Hash functions

MVP requirement:

target_hash = sha256(normalized_target_string)
body_hash = sha256(canonical_body_string)
cid_hash = sha256(cid_string)
leaf_hash = sha256(canonical_leaf_encoding)

5.7 CID format

MVP requirement:

CID version: CIDv1
Multibase: base32 preferred for display
Storage URI format: ipfs://CID

5.8 Timestamp tolerance

MVP requirement:

Client-created timestamp must be within an acceptable application window.
Suggested default: no more than 10 minutes in the future.
Backdated comments are allowed but ranked by commitment time unless app chooses otherwise.

5.9 Nonce rules

Each author must include a unique nonce per target or per comment.

Suggested nonce format:

base64url(random_128_bits)

The nonce prevents duplicate leaf construction and replay ambiguity.

6. Target Normalization

Every comment attaches to a target. Target normalization must be deterministic.

6.1 Target object

{
  "type": "url",
  "id": "https://example.com/article/1"
}

6.2 Target hash

target_hash = sha256(target_type + ":" + normalized_target_id)

6.3 URL normalization

For url targets, clients should:

lowercase scheme and host
remove default ports
normalize trailing slash rules
remove common tracking parameters when configured
preserve path case
sort query parameters, except app-configured ignored params
strip fragments by default unless target type requires fragments

Example:

URL: https://Example.com/story/123?utm_source=x&ref=y
Normalized: https://example.com/story/123?ref=y
Target string: url:https://example.com/story/123?ref=y

6.4 Blockchain target normalization

For Solana objects:

solana_account:<base58_pubkey>
token_mint:<base58_mint>
nft_mint:<base58_mint>
transaction:<base58_signature>
dao_proposal:<protocol>:<proposal_id>

7. IPFS Storage and Data Availability

7.1 IPFS object types

IPFS stores:

7.2 Data availability requirement

A committed comment must be retrievable by CID for applications to render it.

The protocol should use a three-layer availability model:

Protocol pinning: core protocol pins all accepted comments.
Application pinning: apps pin comments for their own targets.
Archival mirroring: important or finalized data is mirrored to Filecoin/Arweave or equivalent.

7.3 Pinning policy

MVP requirement:

All comments submitted through the official SDK/API are pinned by the protocol-operated pinning service.
Applications are encouraged to pin comments they display.
Comments that violate safety policy may be unpinned by protocol-operated infrastructure while remaining cryptographically committed.

7.4 Unavailable CID handling

If a CID cannot be retrieved:

Indexer marks comment as ContentUnavailable.
Apps may display a placeholder.
Author or app may resubmit the same object.
Protocol may request repinning.
Repeated unavailable content from a batcher can reduce batcher reputation.

7.5 Batch manifests

Every Merkle batch should have an IPFS manifest.

{
  "protocol": "comment-protocol",
  "schema": "batch_manifest.v1",
  "batch_id": 1001,
  "tree_id": "global-v1",
  "merkle_root": "0x...",
  "leaf_count": 1000,
  "leaves_cid": "ipfs://CID",
  "created_at": "2026-05-31T00:00:00Z",
  "batch_authority": "SOLANA_PUBLIC_KEY",
  "signature": "authority_signature"
}

7.6 Content safety

The protocol should not promise permanent serving of illegal, abusive, malicious, or unsafe content through protocol-operated gateways.

The correct distinction is:

cryptographic commitment may remain
protocol-operated pinning may stop
gateway serving may stop
app display may hide
moderation state may record action

8. Merkle Batching Specification

Merkle batching is the primary scaling mechanism for normal comments.

8.1 Comment leaf

{
  "schema": "comment_leaf.v1",
  "author": "SOLANA_WALLET_PUBLIC_KEY",
  "target_hash": "hex_sha256",
  "parent": null,
  "cid": "ipfs://CID",
  "cid_hash": "hex_sha256",
  "created_at": "2026-05-31T00:00:00Z",
  "nonce": "random_nonce",
  "signature": "author_signature"
}

8.2 Leaf hash

leaf_hash = sha256(canonical_leaf_encoding)

8.3 Tree model

MVP recommendation:

Use append-only Merkle batches rather than a single mutable global tree.
Each batch has a unique batch_id, tree_id, merkle_root, leaf_count, and manifest CID.

This is simpler than launching with a fully concurrent mutable tree.

8.4 Tree scope

Supported tree scopes:

global
app-specific
target-specific
epoch-specific

MVP recommendation:

Use app-specific epoch batches.

Example:

tree_id = app:<app_id>:epoch:<yyyy-mm-dd-hh>

This reduces contention and allows apps to operate their own batchers.

8.5 Batch size

Suggested batch sizes:

small app: 25–100 comments
medium app: 100–500 comments
large app: 500–2,000 comments
latency-sensitive apps: submit every 30–120 seconds even if batch is not full

MVP default:

Commit every 100 comments or every 60 seconds, whichever comes first.

8.6 Batch authority

MVP requirement:

Only approved batch authorities may submit roots.

V1 production requirement:

Applications may register batch authorities.
Batch authorities must stake COMMENT or be approved by governance/app policy.
Batcher behavior is tracked by reliability metrics.

8.7 Batcher censorship handling

If a user signs a comment and submits it to a batcher but it is not included:

The user/app can resubmit to another batcher.
The app can submit a direct comment record.
The protocol can track failed inclusion complaints off-chain initially.
Future versions may support inclusion promises and slashable batcher commitments.

8.8 Inclusion proofs

Indexers must provide inclusion proofs for batched comments.

Proof response:

{
  "comment_id": "derived_comment_id",
  "batch_id": 1001,
  "tree_id": "app:topnews:epoch:2026-05-31-15",
  "leaf_index": 42,
  "leaf_hash": "0x...",
  "merkle_root": "0x...",
  "proof": ["0x...", "0x..."],
  "solana_tx": "signature",
  "manifest_cid": "ipfs://CID"
}

8.9 Finality

A batched comment is considered protocol-committed after:

Solana transaction is finalized
batch root account or event is indexed
manifest CID is retrievable
comment CID is retrievable
signature verification passes

9. Direct Comment Records and Promotion

9.1 Direct comment records

A direct CommentRecord is a Solana account representing a comment that requires mutable state.

Direct records should be used for:

MVP comments before batching exists
staked comments
reported comments
moderated comments
reward-eligible comments
governance-relevant comments
pinned comments
disputed comments
comments selected by apps for durable state

9.2 Promotion from batch to state

A batched comment can be promoted into a direct record by providing:

batch account
leaf data
Merkle proof
comment CID hash
author
payer

The program verifies inclusion and creates a CommentRecord.

9.3 Promotion triggers

Suggested triggers:

comment receives more than N votes
comment is reported
comment receives a reward
comment is pinned by an app
comment is attached to governance
comment author stakes COMMENT on it
comment is included in an appeal or dispute

9.4 Comment edits

Edits should not mutate history silently.

MVP requirement:

An edit creates a new IPFS CID and links to the prior comment CID or comment ID.
Direct records update latest_cid_hash and emit CommentEdited.
Batched comments use an edit attestation that references the original comment ID.
Apps display edit history according to policy.

9.5 Comment deletion

Deletion is a state marker, not guaranteed erasure.

Supported deletion markers:

DeletedByAuthor
HiddenByApp
ProtocolHidden
ContentUnavailable

10. Solana Program Specification

10.1 Program accounts

ProtocolConfig

pub struct ProtocolConfig {
    pub admin: Pubkey,
    pub treasury: Pubkey,
    pub comment_mint: Pubkey,
    pub base_comment_fee_lamports: u64,
    pub min_comment_stake: u64,
    pub reputation_version: u16,
    pub moderation_version: u16,
    pub paused: bool,
    pub bump: u8,
}

AppRegistry

pub struct AppRegistry {
    pub app_id: [u8; 32],
    pub owner: Pubkey,
    pub policy_cid_hash: [u8; 32],
    pub default_batch_authority: Pubkey,
    pub status: AppStatus,
    pub created_at: i64,
    pub bump: u8,
}

UserProfile

pub struct UserProfile {
    pub owner: Pubkey,
    pub profile_cid_hash: [u8; 32],
    pub created_at: i64,
    pub comment_count: u64,
    pub direct_comment_count: u64,
    pub batched_comment_count: u64,
    pub global_score: i64,
    pub upvotes_received: u64,
    pub downvotes_received: u64,
    pub reports_received: u64,
    pub reports_confirmed: u64,
    pub stake_locked: u64,
    pub status: UserStatus,
    pub bump: u8,
}

AppUserReputation

Optional app-specific reputation account.

pub struct AppUserReputation {
    pub app_id: [u8; 32],
    pub user: Pubkey,
    pub local_score: i64,
    pub local_comment_count: u64,
    pub local_reports_confirmed: u64,
    pub status: UserStatus,
    pub bump: u8,
}

CommentRecord

pub struct CommentRecord {
    pub author: Pubkey,
    pub app_id: [u8; 32],
    pub target_hash: [u8; 32],
    pub parent: Option<Pubkey>,
    pub origin: CommentOrigin,
    pub origin_batch: Option<Pubkey>,
    pub cid_hash: [u8; 32],
    pub latest_cid_hash: [u8; 32],
    pub created_at: i64,
    pub updated_at: i64,
    pub upvotes: u64,
    pub downvotes: u64,
    pub reports: u64,
    pub stake_amount: u64,
    pub status: CommentStatus,
    pub bump: u8,
}

CommentBatch

pub struct CommentBatch {
    pub app_id: [u8; 32],
    pub batch_authority: Pubkey,
    pub batch_id: u64,
    pub tree_id_hash: [u8; 32],
    pub merkle_root: [u8; 32],
    pub manifest_cid_hash: [u8; 32],
    pub leaf_count: u32,
    pub created_at: i64,
    pub status: BatchStatus,
    pub bump: u8,
}

VoteRecord

pub struct VoteRecord {
    pub voter: Pubkey,
    pub comment: Pubkey,
    pub vote_type: VoteType,
    pub weight: u64,
    pub created_at: i64,
    pub bump: u8,
}

ReportRecord

pub struct ReportRecord {
    pub reporter: Pubkey,
    pub comment: Pubkey,
    pub reason_code: u16,
    pub evidence_cid_hash: [u8; 32],
    pub status: ReportStatus,
    pub created_at: i64,
    pub resolved_at: i64,
    pub bump: u8,
}

StakePosition

pub struct StakePosition {
    pub owner: Pubkey,
    pub amount: u64,
    pub locked_until: i64,
    pub purpose: StakePurpose,
    pub related_comment: Option<Pubkey>,
    pub bump: u8,
}

10.2 Core instructions

initialize_protocol()
update_protocol_config()
register_app(app_id, policy_cid_hash, batch_authority)
update_app_policy(app_id, policy_cid_hash)
create_user_profile(profile_cid_hash)
update_user_profile(profile_cid_hash)
create_direct_comment(app_id, target_hash, parent, cid_hash, stake_amount)
edit_direct_comment(comment, new_cid_hash)
delete_direct_comment(comment)
create_comment_batch(app_id, batch_id, tree_id_hash, merkle_root, manifest_cid_hash, leaf_count)
promote_batched_comment(batch, leaf_hash, proof, cid_hash, target_hash, author)
upvote_comment(comment)
downvote_comment(comment)
remove_vote(comment)
report_comment(comment, reason_code, evidence_cid_hash)
resolve_report(report, action)
stake_comment_tokens(amount, purpose, related_comment)
unstake_comment_tokens(stake_position)
slash_stake(stake_position, amount, reason)
set_user_status(user, status)
set_comment_status(comment, status)

10.3 Events

The program should emit events for indexers.

CommentCreated
CommentEdited
CommentDeleted
CommentBatchCommitted
CommentPromoted
VoteCast
VoteRemoved
ReportCreated
ReportResolved
UserReputationUpdated
AppReputationUpdated
StakeCreated
StakeReleased
StakeSlashed
ModerationAction
AppRegistered

11. Reputation Specification

Reputation should exist at two levels.

11.1 Global reputation

Global reputation is portable across apps.

It reflects broad trustworthiness:

comment history
confirmed reports
accurate reports
stake history
account age
moderation history
protocol-level abuse

11.2 App-specific reputation

App-specific reputation reflects trust within a particular application or community.

Examples:

TopNews reputation
NFT marketplace reputation
DAO forum reputation
wallet security reputation
token discussion reputation

11.3 Reputation v0 formula

Initial global score:

global_score = 100
             + weighted_upvotes_received
             - weighted_downvotes_received
             + accurate_reports_bonus
             - confirmed_reports_penalty
             - spam_penalty
             - phishing_penalty
             + stake_bonus
             + age_bonus

Suggested parameters:

base score: 100
upvote received: +1 * voter_weight
downvote received: -1 * voter_weight
accurate report: +3
false report: -2
confirmed spam report: -25
confirmed phishing/scam report: -100
stake bonus: capped sqrt(staked_COMMENT)
age bonus: capped at +25
daily positive cap: +50
daily negative cap: -100

11.4 Voter weight

voter_weight = min(5, 1 + reputation_tier_bonus + stake_tier_bonus)

MVP can simplify this to:

all votes weight = 1
trusted users weight = 2
moderators weight = 3 for report review only

11.5 Reputation tiers

New: score < 100 or account age below threshold
Active: score 100–249
Trusted: score 250–999
Moderator: assigned or elected role
Limited: enforcement state
Banned: enforcement state

11.6 Reputation effects

Reputation affects:

rate limits
link posting
media posting
vote weight
report weight
staking requirements
comment ranking
reward eligibility
moderation queue priority

11.7 Wallet linking

Wallet linking must be conservative.

MVP requirement:

A user may link wallets in the app layer.
On-chain reputation remains wallet-specific at launch.
Future versions may support profile-level reputation with anti-abuse checks.

12. Moderation Specification

Moderation has four distinct layers.

12.1 Protocol moderation state

This is shared on-chain state.

Used for severe actions:

ProtocolHidden
Slashed
Banned
Limited
Restored

12.2 App display state

Each app decides what it displays.

Examples:

HiddenByApp
CollapsedByApp
PinnedByApp
FeaturedByApp
RequiresReview

12.3 Indexer availability state

Indexers may mark content:

ContentUnavailable
SignatureInvalid
CIDMismatch
UnsafeContent
MalformedObject

12.4 Pinning/gateway state

Protocol-operated services may stop pinning or serving unsafe content without claiming the underlying commitment disappeared.

12.5 Report reasons

Spam
Phishing
Malware
Scam
Harassment
Impersonation
IllegalContent
NSFW
OffTopic
Doxxing
Other

12.6 Report lifecycle

Open
UnderReview
Dismissed
Confirmed
Appealed
Resolved

12.7 Enforcement actions

NoAction
HideInApp
ProtocolHide
LimitUser
BanUser
ReduceReputation
SlashStake
RestoreComment
RestoreUser

12.8 Slashing rules

Stake slashing should require stronger process than hiding.

MVP requirement:

Only protocol admin or approved moderation authority can slash stake.
Slashing requires a confirmed report reason.
Slashing emits a public event.
Slashed user can appeal through off-chain governance process initially.

Future requirement:

Token governance or elected moderation councils control slashing policies.

12.9 Moderation evidence

Evidence may be stored as an IPFS object.

{
  "schema": "moderation_evidence.v1",
  "reporter": "wallet",
  "comment_id": "id",
  "reason": "Phishing",
  "description": "Contains malicious wallet drain link",
  "screenshots": [],
  "urls": [],
  "created_at": "2026-05-31T00:00:00Z"
}

13. Privy and User Experience Requirements

13.1 Wallet model

MVP recommendation:

Use Privy embedded Solana wallets for mainstream users.
Support connected Solana wallets for crypto-native users.

13.2 Normal comment UX

For normal comments:

User signs comment payload.
App uploads to IPFS.
App or protocol batcher submits Merkle root to Solana.
User does not manually pay gas.

13.3 On-chain action UX

Users may directly sign Solana transactions for:

staking COMMENT
unstaking COMMENT
claiming rewards
governance voting
appealing disputes
creating direct comments if required

13.4 Gas sponsorship

MVP requirement:

Apps or protocol relayers sponsor normal comment commitments.
Low-reputation or high-volume users may be rate-limited or required to stake.

13.5 Account recovery

Privy handles embedded wallet recovery according to its configuration. Comment Protocol should not rely on private recovery assumptions for protocol security.

14. Token Utility and Economics

$COMMENT should improve protocol quality without making basic commenting impossible.

14.1 Utility

staking for trust
anti-spam deposits
posting limits
fee discounts
moderator rewards
accurate reporter rewards
quality comment rewards
app integration incentives
storage/indexer incentives
governance voting

14.2 Posting policy

Suggested MVP policy:

Normal comment: free to user, app-sponsored
Low-rep high-frequency comment: rate-limited
Comment with link: stake or sufficient reputation required
Comment with media: stake or Trusted status required
Repeated reports: staking requirement increases

14.3 Rewards caution

Rewards should not launch too early.

Requirement:

Do not introduce large public comment rewards until anti-sybil, moderation, and abuse systems are proven.

Early rewards should be limited to:

trusted moderators
accurate reporters
app integrations
manual community programs

15. Cost Model

15.1 Direct account model

Each direct comment account requires transaction fees and rent-exempt account storage.

Best for:

MVP
important comments
staked comments
reported comments
rewarded comments
moderation-sensitive comments

15.2 Merkle batch model

Many comments share one Solana commitment.

Best for:

normal comments
high-volume apps
consumer feeds
low-cost posting
app-sponsored UX

15.3 Hybrid requirement

Production architecture should use:

Profiles: Solana accounts
Global reputation: Solana accounts
App reputation: Solana accounts or periodic roots
Moderation: Solana accounts
Staking: Solana accounts
Normal comments: IPFS + Merkle batches
Important comments: promoted Solana accounts
Search: off-chain indexer

16. SDK and API Requirements

16.1 TypeScript SDK

Required methods:

createProfile(profileMetadata)
updateProfile(profileMetadata)
createComment(target, body, options)
replyToComment(parentId, body, options)
editComment(commentId, body, options)
deleteComment(commentId)
fetchThread(target, filters)
fetchComment(commentId)
fetchUserProfile(wallet)
fetchUserReputation(wallet, appId?)
upvote(commentId)
downvote(commentId)
report(commentId, reason, evidence)
stake(amount, purpose)
unstake(stakePosition)
verifyComment(comment)
verifyCommentSignature(comment)
verifyMerkleInclusion(comment, proof)

16.2 React widget

<CommentThread
  target={{ type: "url", id: "https://example.com/article/1" }}
  appId="topnews"
  sort="top"
  moderation="app-default"
/>

16.3 API endpoints

POST /v1/comments
GET /v1/thread/:targetHash
GET /v1/comment/:commentId
GET /v1/comment/:commentId/proof
POST /v1/comment/:commentId/edit
POST /v1/comment/:commentId/delete
POST /v1/comment/:commentId/vote
POST /v1/comment/:commentId/report
GET /v1/user/:wallet
GET /v1/user/:wallet/reputation
POST /v1/ipfs/pin
GET /v1/batch/:batchId
GET /v1/app/:appId/policy

16.4 Webhooks

comment.created
comment.committed
comment.promoted
comment.edited
comment.deleted
comment.reported
comment.moderated
user.reputation_updated
batch.committed

17. Indexer Requirements

The indexer is critical infrastructure.

It must:

read Solana program accounts
read Solana events
resolve IPFS CIDs
verify comment object schemas
verify author signatures
verify target hashes
verify CID hashes
verify Merkle proofs
track thread structure
track moderation state
track reputation state
serve fast APIs
expose proof data
handle unavailable content

17.1 Invalid object handling

If a comment object fails verification:

SignatureInvalid
CIDMismatch
TargetHashMismatch
MalformedSchema
UnsupportedVersion
ContentUnavailable

Apps should not display invalid comments by default.

18. Ranking Requirements

Ranking should be modular and app-configurable.

Supported ranking modes:

new
top
hot
controversial
trusted
following
token_holder
moderator_picked
app_default

Default ranking formula:

rank_score = vote_score
           + author_reputation_bonus
           + freshness_bonus
           + app_reputation_bonus
           - report_penalty
           - low_reputation_penalty

Apps may override ranking.

19. Security Requirements

19.1 Replay protection

Use domain-separated signatures, nonces, and target hashes.

19.2 Signature verification

All comments must verify against the claimed author wallet.

19.3 CID verification

The retrieved IPFS object must hash to the expected CID, and the CID string must hash to the committed CID hash.

19.4 Batcher trust minimization

Batchers cannot forge comments because comments are signed. Batchers can censor or delay comments, so users/apps must be able to resubmit through other batchers.

19.5 Moderation power limits

Early admin powers must be transparent. Long-term slashing and protocol-level hiding should move toward governance or elected moderation councils.

19.6 Spam resistance

Spam controls include:

rate limits
stake requirements
reputation thresholds
link restrictions
media restrictions
report penalties
batcher filtering
app-specific policies
proof-of-humanity integrations later

20. MVP Scope

The MVP should prove the core product, not the entire governance system.

20.1 MVP includes

Privy embedded wallet login
connected Solana wallet support
comment signing
IPFS comment storage
protocol pinning service
direct Solana comment accounts OR simple batch commitments
user profiles
basic reputation counters
upvotes/downvotes
reports
admin moderation dashboard
React comment widget
TypeScript SDK
indexer/API
TopNews-style integration

20.2 MVP does not need

full DAO governance
public rewards farming
complex token emissions
fully decentralized indexers
fully decentralized moderation
cross-chain identity
media comments
advanced proof-of-humanity

20.3 Recommended MVP path

Phase 1 should use direct comment records if engineering speed matters.

Phase 2 should add Merkle batching once comment volume and product UX are validated.

Alternative path:

Build Merkle batching from day one if the team has strong Solana engineering resources.

21. Roadmap

Phase 0 — Final Specification

canonical comment schema
target normalization
signature standard
IPFS pinning policy
Solana account layouts
reputation v0
moderation v0
SDK interface

Phase 1 — MVP Product

Privy onboarding
comment widget
IPFS storage
direct comments
basic voting
basic reports
admin moderation
indexer/API

Phase 2 — Attestation Scale

Merkle batches
batch manifests
proof API
batch authorities
comment promotion
app-specific batchers

Phase 3 — Reputation and Token Utility

COMMENT staking
rate-limit staking
trusted reporters
moderator incentives
app-specific reputation
limited rewards

Phase 4 — Decentralization

independent indexers
storage provider incentives
governance controls
moderation councils
decentralized app registry

Phase 5 — Internet Comment Graph

cross-app reputation
wallet comments
transaction annotations
token/NFT discussion
DAO proposal comments
AI-agent comments
search/discovery layer

22. Technical Requirement Summary

The protocol must satisfy these requirements.

22.1 Comment requirements

Every comment has canonical JSON.
Every comment is signed by the author.
Every comment has a deterministic target hash.
Every comment has an IPFS CID.
Every comment has either direct Solana state or Merkle inclusion in a committed batch.
Every displayed comment can be verified by clients or indexers.

22.2 Storage requirements

Comment bodies live on IPFS.
Protocol-operated infrastructure pins accepted comments.
Apps should pin comments they rely on.
Unavailable CIDs are tracked explicitly.
Unsafe content may be unpinned or not served by protocol gateways.

22.3 Solana requirements

Solana stores profiles, reputation, batches, moderation, staking, reports, and promoted comments.
Normal comments should not require one account each at scale.
All important moderation and slashing actions emit events.

22.4 Reputation requirements

Global reputation is portable.
App-specific reputation is local.
Reputation affects rate limits, ranking, reports, and posting privileges.
Reputation changes must be transparent and versioned.

22.5 Moderation requirements

Protocol moderation and app moderation are separate.
Hiding is not deletion.
Slashing requires confirmed abuse.
Appeals should be supported.
Moderation actions should be auditable.

22.6 UX requirements

Normal users can post through Privy without manually buying SOL.
Crypto-native users can connect external Solana wallets.
Apps can sponsor comments.
Staking, rewards, and governance use explicit wallet transactions.

23. Open Questions

These questions should be resolved before implementation lock.

  1. Should MVP launch with direct comment records first, or Merkle batches from day one?
  2. What is the exact maximum comment size?
  3. Should app-specific reputation be on-chain accounts or off-chain roots initially?
  4. Who are the first approved batch authorities?
  5. What is the initial staking requirement for links?
  6. What moderation actions can slash stake at launch?
  7. Should comments with unsafe links be prevented before IPFS pinning?
  8. How many replicas should the protocol pinning layer maintain?
  9. Should apps pay per comment, per monthly volume, or through token staking?
  10. When should public reward emissions begin?

24. Conclusion

Comment Protocol is a shared comment and reputation layer for the internet.

The protocol's key architectural insight is that comments should begin as signed attestations, not expensive mutable accounts. Solana should settle identity, commitments, reputation, moderation, staking, and disputes. IPFS should store comment content. Merkle batching should make normal comments cheap. Direct Solana accounts should be reserved for stateful or important comments.

This creates a scalable path toward portable comments, transparent moderation, and user-owned reputation across every app.

In one sentence:

Comment Protocol is the open, verifiable, reputation-aware comment graph for the internet.

</user_query>