How reputation works

The Reputation Credential program issues non-transferable credentials bound to wallets. This page explains what those credentials represent, how they're issued, and why they can't be moved.

The core idea

A reputation credential is a permanent record on chain that says: this wallet, at this time, was awarded this credential by this issuer.

What's special:

• It cannot be transferred. Once issued to your wallet, only that wallet has it.
• It cannot be sold. There is no marketplace mechanic.
• It is verifiable. Anyone can read the on-chain record and verify the issuer's authority.
• It can be revoked. If something changes (the issuer makes a mistake, the credential becomes invalid), it can be marked revoked. The record stays — only the revoked flag flips.

This is what blockchain people call soulbound. Sciencera implements it in the simplest possible way: there's no transfer instruction in the program at all. A credential simply has nowhere to go.

What kinds of credentials exist

Each issuer multisig holds permission for specific credential types. The Academy issuer can issue Academy credentials but not Lab Verified ones. This separation prevents one compromised key from issuing across all domains.

What's stored for each credential

The on-chain record includes:

• Subject wallet address — who the credential is bound to
• Issuer wallet address — who issued it
• Credential type — Academy / Reviewer Contribution / Milestone Participation / Lab Verified
• Issuance key fingerprint — a hash that makes the credential unique per (subject, type, key)
• Slug — short identifier (e.g., a track slug)
• Title — display title (e.g., "Peptide Science 101")
• Content URI — optional pointer to credential metadata off chain
• Proof hash — fingerprint of the issuance payload
• Score — 0-100 for credentials with a passing threshold (Academy); 0 otherwise
• Issued at — timestamp
• Revoked status — whether revoked, when, by whom, and a fingerprint of the revocation reason
• Optional external mint — an optional token-2022 non-transferable mirror

Why "issuance key fingerprint"?

The issuance key fingerprint is what makes a credential unique per (subject, type, key). Without it, you couldn't tell apart "Academy track A passed in March" from "Academy track A passed again in April" — or you'd have to allow only one credential per type per wallet, ever.

By convention:

These are conventions, not enforced on chain. The blockchain only cares that two credentials with the same (subject, type, fingerprint) can't both exist.

How issuance works

When the Academy issuer issues a credential to your wallet (after you pass a track):

1. The issuer prepares the issuance payload — track slug, your wallet, your score, the timestamp.
2. The issuer fingerprints the payload (proof hash) and computes the issuance key fingerprint.
3. Optionally, the issuer uploads metadata to off-chain storage and gets back a content URI.
4. The issuer signs an issue_credential transaction with the on-chain program.
5. The program validates everything:
   • The issuer is active and permitted for this credential type
   • The slug, title, and URI are within byte limits
   • The proof hash is non-zero (you can't issue an empty fingerprint)
   • The score is between 0 and 100
   • There isn't already a credential at this (subject, type, key) — no double-issuing
6. The program creates a new credential account bound to your wallet.
7. A CredentialIssued event is emitted.

You don't sign — issuance is by the issuer, not by the recipient. This is by design: a credential is something done to you (you earned it), not something you create.

Revocation

Sometimes a credential needs to be revoked — a mistake, an issuance to the wrong wallet, an issuer's policy change. The program supports it:

• The admin can revoke any credential.
• The original issuer can revoke credentials they issued, if they were granted revoke permission.

Revocation:

• Sets the revoked flag to true
• Records the timestamp and the wallet that revoked
• Records a fingerprint of the revocation reason (so the explanation can be verified later)
• Does not delete the credential record — history is preserved

The revoked flag is queryable. Verifiers should always check it before trusting a credential.

What "non-transferable" really means

A token-based credential could theoretically be transferred. Sciencera avoids this by not implementing transfer at all.

There's no transfer_credential instruction. Period. The program has no path to move a credential from one wallet to another.

If a wallet is compromised, the credential goes with the wallet. There's no platform-level "rebind to a new wallet" mechanism in v1 — that would re-introduce a transfer-shaped path. The compromised path is: the user revokes the old credential and re-earns the new one with a fresh wallet.

This trade-off is deliberate. It keeps the soulbound property absolute.

Optional external mint

The program supports attaching a token-2022 non-transferable mirror mint. This is optional and admin-controlled:

• The credential PDA stays the canonical record.
• The mirror mint exists for wallet display — so wallets that show NFTs can show the credential.
• The mirror is opt-in; the program does not force it.

If the mirror is set, it's referenced in the credential's external_mint field. This is metadata, not authority — the canonical credential is still the on-chain account.

What's enforced, ever

• Credentials are non-transferable by absence of a transfer instruction.
• Issuers can only issue types they're permitted for.
• Issuers can only revoke their own past issuances (unless they're the admin).
• Each (subject, type, issuance_key) triple is unique — no double-issuance.
• All credential accounts have version + reserved fields for safe future migrations.

Where to go next

• The blockchain layer — broader authority model
• How proposals stay tamperproof — the proposal lifecycle
• Where your data lives — on chain, off chain, browser
• Compliance — regulator framing for credentialing