[ PRODUCT // PROTOCOL ]
← BACK TO HOME

SHARP
PROTOCOL.

The reputation layer of the AI stack.

Audited smart contracts and open schemas for writing verified work to chain and reading it back. Deployed on Polygon, Base, and Solana.

Sharp Protocol is not a chain. No validators, no blocks, no consensus of its own.

It specifies four things: the schema of a reputation record, the authority required to issue one, the stake required to attest to it, and the interface for querying the graph.

PROTOCOL // STATUSMAINNET
SKILLS ON CHAINLIVE
REWARDS ON CHAINLIVE
BADGES ON CHAINLIVE
SHARP TOKENLIVE
CONTRACTSAUDITED · DEPLOYED

Everything above is deployed on mainnet today. Everything marked roadmap below is not.

[ THE PRIMITIVES ]

SEVEN VERBS.
THAT IS THE PROTOCOL.

Everything Sharp does is one of these seven operations. Four are deployed. Three are specified and on the roadmap, and are marked as such.

RECORDLIVE

Write a piece of verified work to chain. A completed course, a merged contribution, a delivered task. The record names what was done, who did it, and who confirmed it.

VERIFYLIVE

Confirm a claim before it is written. A test result, a peer review, a completion check. Unverified claims never enter the graph, which is what keeps it worth reading.

SCORELIVE

Turn a history of records into a number. Weighted by what the work was, how recent it is, and the standing of whoever verified it.

SETTLELIVE

Pay against the record. Daily reward distribution, badge minting, and marketplace settlement all run in SHARP.

VOUCHROADMAP

Attest to someone else by staking your own score against them. If they fail, you take the hit. This is what makes an endorsement expensive enough to mean something.

DISPUTEROADMAP

Challenge a record. Resolution is adjudicated by the community, and the outcome adjusts the standing of everyone who vouched.

QUERYROADMAP

Read the graph without permission. Filter by skill, volume, dispute rate, or the standing of whoever did the verifying. This is the operation that makes the record worth writing, and the one an employer or an orchestrator actually calls.

[ THE RECORD ]

WHAT ACTUALLY
GOES ON CHAIN.

Not a profile. Not a score you can buy. A record of one piece of work, and the people who stood behind it.

REPUTATION RECORD
subject0x… human or agent
typeskill | contribution | delivery
claimwhat was done
issuercommunity that wrote it
verifierwho confirmed it
weightpoints assigned
issuedblock timestamp
statusactive | disputed
OWNED BY THE SUBJECT

The record belongs to whoever earned it, not to the community that issued it. It stays readable if they leave, and it stays readable if the community shuts down.

ISSUER AND VERIFIER ARE SEPARATE

Who wrote the record and who confirmed the claim are different fields. A reader can weigh a record by how much they trust the verifier, not just the platform.

NO SCORE IS STORED

Reputation is computed from records, never written as a number. There is nothing to edit, inflate, or sell. Change the weighting and every score recomputes from the same underlying history.

[ ARCHITECTURE ]

FOUR LAYERS.
ONE GRAPH.

Applications write and read. The SDK normalises. The protocol contracts hold state. Settlement is delegated to chains that already have security and liquidity.

L1 — APPLICATIONSPARTNER COMMUNITIESC# CORNER · HACKINDIA · GOPUREENTERPRISE INTEGRATIONSEXISTING APPS · LOYALTY · HRSHARP PLATFORMSELF-HOSTED · WHITE-LABELAGENT RUNTIMESAGENTS READ · AGENTS ARE READL2 — SHARP SDK / APIVERIFICATION ADAPTERSIDENTITY BINDINGGAS ABSTRACTIONSCHEMA VALIDATIONQUERY CLIENTOFF-CHAIN VERIFICATIONAI screening · fraud, sybil, collusionAutomated tests · CI, assessmentsCommunity review · peer, moderatorSIGNED VERIFICATION → REGISTRYL3 — PROTOCOL CONTRACTSATTESTATIONREGISTRYSTAKING &VOUCHINGREWARDSPOOLSETTLEMENTROUTERQUERYINDEXUpgradeable behind audited proxies. State lives here; logic can evolve without migrating records.Each partner may deploy its own rewards-pool instance with custom rules, interoperable with the shared registry.L4 — SETTLEMENTPOLYGONBASESOLANAANY EVM / SVMBridged supply. One canonical graph, mirrored per chain.The protocol owns the record. It does not own the chain, the application, or the verifier.Every layer above and below it is replaceable. The registry is the only thing that has to be shared.SOLID — SPECIFIED · DASHED — PLUGGABLE · AMBER — TOKEN-DENOMINATED · CYAN — AGENT SURFACE
[ HOW IT WORKS ]

THE LIFE OF
ONE RECORD.

From a piece of work to a queryable attestation, six steps. The protocol is only involved in four of them, which is deliberate.

01 · OFF-CHAIN

Work happens

A member answers a question, completes a course, ships a task. An agent finishes a job. The application observes it.

02 · OFF-CHAIN

Verification

AI screening for fraud and sybil patterns, then a test result or a human reviewer. The verifier signs. Nothing unverified proceeds.

03 · ON-CHAIN

Record

The SDK writes an attestation to the registry: subject, claim, issuer, verifier signature, weight. The issuer pays the write fee in SHARP.

04 · ON-CHAIN

Score

The subject's score recomputes from the full record set. No score is stored, so there is nothing to tamper with. Weights are a governed parameter.

05 · ON-CHAIN

Settle

The daily rewards pool distributes SHARP in proportion to the day's weighted records. Badges mint. Marketplace and bounty settlement route through escrow.

06 · ON-CHAIN

Query

Any reader, human or agent, queries the index. Filter by skill, volume, dispute rate, verifier standing. Enterprise readers pay per query in SHARP.

Steps 01 and 02 are off-chain by design. Putting raw activity on chain is expensive and leaks nothing useful. The protocol's job starts at the moment a claim has been verified and signed, and stops at the moment it has been read.

[ VALUE ACCRUAL ]

WHERE SHARP
MOVES.

SHARP is the unit of account for every protocol operation. Four inflows, one router, three destinations. Usage and scarcity are coupled by design.

INFLOWS — PAID IN SHARPWRITE FEEISSUER · PER RECORDQUERY FEEENTERPRISE & AGENT READERS · PER QUERYSETTLEMENT FEEMARKETPLACE · BOUNTIES · MEMBERSHIPSSTAKEVOUCHER · LOCKED, NOT SPENTFEE ROUTERSplit by category.Ratios are a governed parameter.DESTINATIONSBURN5–15% BY CATEGORY · PERMANENTCOMMUNITY REWARDS POOL34% OF SUPPLY · 15-YEAR EMISSIONFOUNDATION TREASURYAUDITS · LIQUIDITY · GRANTS · BUYBACKVOUCH FAILSDISPUTE UPHELD → SLASHSLASHED STAKE → BURNDAILY EMISSION → CONTRIBUTORS → NEXT RECORD
DEFLATIONARY PRESSURE

A share of every fee is burned. Unclaimed daily emissions are burned. Slashed stake is burned. Supply tightens as usage grows, without a buyback being required.

USAGE-LINKED EMISSION

The daily pool releases in proportion to verified activity, capped by the emission schedule. Low activity releases less. Fees top the pool up, so mature communities subsidise less from supply.

STAKE IS NOT A FEE

Vouching locks SHARP, it does not spend it. Stake returns when the attestation stands. It is destroyed only when a dispute is upheld, which makes an endorsement costly to give carelessly and free to give well.

[ WHY A SHARED GRAPH ]

ISSUANCE IS SOLVED.
LEGIBILITY IS NOT.

Token issuance is commoditized. Any SDK can mint a balance and abstract the wallet away.

The unsolved problem is portability. A balance issued by one platform is legible only to that platform. It carries no history, no verification path, and no value outside its origin. It is a database row with a gas fee.

Sharp writes to a single attestation graph shared by every issuer on the protocol. Each record specifies subject, issuer, verifier, and weight, so any party can read and weight it without trusting the platform that produced it. Reputation composes across issuers instead of terminating at each one.

The result is a network effect on the read side. Every additional issuer raises the query value of the graph for every existing participant.

ISOLATED ISSUANCE
issuer A → balance → readable by A
issuer B → balance → readable by B
issuer C → balance → readable by C
n issuers → n silos
SHARED ATTESTATION GRAPH
issuer A → graph ← issuer B
issuer C → graph ← issuer D
any reader → query( subject )
n issuers → one graph
COLD START

Attestation networks fail at cold start. An empty graph returns nothing, so nobody queries it, so nobody writes to it.

Sharp launches into an existing population. The graph has subjects before it has a spec sheet.

3M+
DEVELOPERS · C# CORNER
100K
STUDENT BUILDERS · HACKINDIA
[ HUMANS AND AGENTS ]

SAME GRAPH.
OPPOSITE DIRECTION.

A person and an AI agent both need to be trusted, but they cannot earn that trust the same way. The protocol treats them differently on purpose.

HUMANS

Learn, certify, contribute, mentor. Verified by peer review, tests, and community vouching. A person can attest to another person, and stakes their own standing to do it.

PROOF OF SKILL · PROOF OF CONTRIBUTION
AI AGENTS

Tasks completed, uptime, dispute rate. Verified by measured behaviour, security review, and community review. An agent cannot attest to anything, including itself. The community vouches for it.

PROOF OF DELIVERY · PROOF OF PARTICIPATION

That asymmetry is the reason the human graph has to exist first. An agent's reputation is only as good as the people willing to put their own score behind it.

[ BUILD ON IT ]

THREE WAYS IN.
ONE GRAPH OUT.

Partners integrate at the depth that fits them. All three write to and read from the same registry, so the choice is about surface area, not about which network you join.

MODE A · SDK

Write from your app

Keep your product. Add a verification adapter and start issuing attestations from events you already track. Days, not quarters.

C# CORNER · HACKINDIA · CSHARP.TV
MODE B · PLATFORM

Run the full stack

Self-host or white-label Sharp Platform. Wallets, rewards engine, marketplace, and agentic moderation, already wired to the protocol.

NEW COMMUNITIES · DAOS · BRANDS
MODE C · READ-ONLY

Query the graph

Issue nothing. Read reputation to hire, to gate access, to price risk, or to pick an agent. Pay per query in SHARP.

EMPLOYERS · LENDERS · ORCHESTRATORS
WRITE · MODE A
sharp.attest({
  subject:  member.address,
  type:     "contribution",
  claim:    "answer_accepted",
  weight:   10,
  verifier: reviewer.sign(eventHash)
})
// → record id · fee paid in SHARP · score recomputed
READ · MODE C
sharp.query({
  type:      "agent",
  tasks:     { gte: 500 },
  disputes:  { lt: 0.02 },
  verifiers: { minTier: 3 }
})
// → ranked subjects · fee paid in SHARP

Interface shape shown for illustration. Bindings for TypeScript, Python, and Solidity.

[ TRUST MODEL ]

WHAT IT TAKES
TO LIE.

A reputation system is only as good as the cost of faking it. Every attack surface is met with a cost, not a rule.

SYBILMANY FAKE IDENTITIES

Records need a signed verifier, and verifiers have standing that is itself on chain. A thousand wallets with no verified history are a thousand zeros. AI screening flags farming and collusion patterns before anything is written.

COLLUSIONVERIFIERS VOUCH FOR EACH OTHER

Vouching stakes the voucher's own score. A ring that attests to itself concentrates risk; one upheld dispute slashes every member of it. Collusion becomes a shared liability rather than a shared gain.

ISSUER CAPTUREA PLATFORM INFLATES ITS OWN MEMBERS

Issuer and verifier are separate fields. Readers weight records by verifier standing, not issuer identity. An issuer that inflates finds its records discounted by every reader on the graph.

SCORE TAMPERINGEDIT THE NUMBER

There is no number to edit. Scores are derived from immutable records at read time. Changing a score means changing history, on chain, in public.

CONTRACTS
THIRD-PARTY AUDITED · UPGRADEABLE PROXIES · OPEN SOURCE
KEYS
MPC WALLETS · SOCIAL RECOVERY · NO SEED PHRASE FOR MEMBERS
[ GOVERNANCE & ROADMAP ]

STEWARDED, THEN
HANDED OVER.

The Sharp Innovation Foundation holds the governed parameters today: fee ratios, weights, emission curve, verifier tiers. Control moves to token holders in stages, as the graph earns the right to run itself.

PHASE 1 · LIVE

Foundation

  • SHARP token live on Polygon & Base
  • Skills, rewards, badges on chain
  • First issuer: C# Corner
  • Contracts audited & deployed
PHASE 2

Attestation

  • VOUCH with staked SHARP
  • DISPUTE and slashing
  • Verifier tiers
  • Sharp Platform open release
PHASE 3

Agents

  • QUERY index & paid reads
  • Agent registry & SDK
  • Agent-to-agent settlement
  • Solana settlement
PHASE 4

Decentralise

  • Token-holder votes on parameters
  • Treasury under DAO control
  • Permissionless issuer onboarding
  • Foundation steps back to steward
[ WHERE IT SETTLES ]

DEPLOYED, NOT
OPERATED.

Sharp runs no infrastructure of its own. The contracts sit on chains that already have security, liquidity, and users, and the reputation graph is the same graph on all of them.

POLYGONBASESOLANAYOUR CHAIN

AUDITED

The deployed contracts have been through third-party audit. They hold and distribute value for real communities, so this is not optional.

OPEN TO READ

Records are public. Anyone can read the graph without asking Sharp for access, which is the whole point of putting it on chain rather than in a database.

CHEAP TO WRITE

Reputation only works if writing a record costs almost nothing. Sharp settles on low-fee networks so a single answered question is worth recording.

[ GET STARTED ]

READ THE GRAPH.
WRITE TO IT.

Sharp Protocol is the layer underneath every community on the network. If you are building something that needs to know who can be trusted, human or agent, this is the part you plug into.