Reputation

Nibgate reputation starts with content. A creator should not earn abstract trust points just for existing; trust should come from paid unlocks, receipts, verified source health, and onchain ratings attached to actual resources.

Current MVP reputation uses analytics as context, but reputation-critical inputs are proof-gated. Payment/unlock receipts need provider proof, and ratings are accepted through indexed onchain rating events after unlock eligibility is proven.

Unlocks stay creator-site native by default. The creator site/package handles x402, Gateway, or wallet payment flows. Nibgate verifies and indexes the receipt, then enables reputation actions after unlock eligibility is proven.

Reputation hierarchy

Content reputation is the primary score. Site reputation and creator reputation roll up from content reputation.


verified unlock/payment receipt
  -> eligible wallet or agent
  -> onchain content rating
  -> indexed rating proof
  -> content reputation, 0.0-5.0 stars
  -> site reputation, 1-100
  -> creator reputation, 1-100

A creator can have a strong overall reputation while a specific new piece is still unproven. A new creator can also build trust quickly if their content earns strong ratings from wallets or agents that actually unlocked the work.

Reputation objects

A 0.0-5.0 star score for a specific article, image, music drop, video, or paid route.

Content reputation

A 1-100 score for a verified domain, based on content quality and source health.

Site reputation

A 1-100 score for the wallet/account that owns verified sites.

Creator reputation

Ratings from agent wallets after verified unlock/payment flows.

Agent ratings

Rating rule

A rating should only be accepted after a verified unlock.

The rule is:


No verified unlock receipt -> no rating accepted

The default unlock path does not need to go through a Nibgate payment contract. A creator site can keep using x402, Gateway, or direct wallet payment flows. The package reports the receipt, Nibgate verifies/indexes it, and the wallet becomes eligible to rate.

Onchain rating model

The rating itself is an onchain event after eligibility is proven. The package submits the rating transaction from the visitor or agent wallet, then the Nibgate backend indexes the event and accepts it only when that wallet has a matching unlock receipt/proof for the content.


rateContent(bytes32 contentId, uint8 rating, bytes32 reviewHash, string calldata unlockRef)

Recommended encoding:

contentId: deterministic hash of site, route, and resource id.
rating: 1-50, where 45 means 4.5 stars.
reviewHash: optional hash of a text review stored offchain.
unlockRef: proof or attestation that the wallet unlocked the content (a payment id, tx hash, or unlock receipt reference).
msg.sender: wallet or agent wallet that paid/unlocked.

The proof can be a Nibgate/creator attestation, an indexed x402 receipt, or a future onchain unlock receipt if a site chooses to use a contract-based unlock rail.

End-to-end rating flow

Publish content

The creator site uses the Nibgate package to publish metadata for a paid resource.

Unlock content

A viewer or agent pays through the creator site’s wallet-native flow: x402, Gateway, direct wallet payment, or another supported rail.

Report receipt

The package reports the unlock/payment receipt to Nibgate with the buyer wallet, content id, amount, provider, and receipt reference.

Verify eligibility

Nibgate verifies/indexes the receipt and marks that wallet or agent as eligible to rate the content.

Rate onchain

The wallet submits a rating transaction using its unlock proof.

Index rating event

Nibgate indexes the rating event and updates content stars once the rating/indexer adapter is live.

Roll up reputation

Content stars affect site reputation and creator reputation.

Content reputation

Content reputation answers whether a specific resource is useful, current, accurately described, and worth unlocking.

Public content cards can show a familiar 0.0-5.0 star rating. Under the hood, the score should come primarily from ratings submitted by wallets or agents that actually unlocked the content.

Supporting signals can include:

completed unlocks
payment receipts
onchain rating events
verified views
unlock attempts
time spent
citations
stale or misleading metadata penalties

Site reputation

A site can have its own health: verified, stale, removed, frequently updated, high conversion, or repeatedly disputed.

Site reputation should be a weighted rollup from content ratings on that domain plus source health signals like active widget checks, valid ownership, payment consistency, and content freshness.

Creator reputation

Creator reputation is a 1-100 score attached to the wallet/account that owns verified sites.

It should roll up from:

content star ratings
site reputation
number of verified useful resources
unlock success
payment receipt quality
buyer/agent rating history
penalties from broken, removed, or misleading content

Agent ratings

Agents can rate content after unlocking it, using the same eligibility and rating path as human wallets.

This gives Nibgate a content-side reputation layer that complements agent identity systems: agents can discover content, pay/unlock it, rate it, and later prove that feedback came from an accountable wallet.

Why not mint every content item?

Minting each content item adds too much setup and implies ownership semantics that Nibgate does not need.

The better default is:


content stays on creator site
content id is deterministic
unlock/payment stays creator-site native
receipt proves rating eligibility
rating/reputation can be onchain or attested
Nibgate indexes and rolls up reputation

That keeps creator setup simple while making ratings and reputation progressively verifiable.