> For the complete documentation index, see [llms.txt](https://parad0xlabs.gitbook.io/parad0xlabs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://parad0xlabs.gitbook.io/parad0xlabs-docs/dark-null-protocol-zk-privacy-and-identity/ghostscore.md).

# GhostScore

> **Status: in design.** GhostScore is a roadmap design, not a shipped feature. Nothing on this page is built or deployed under the name "GhostScore." What *is* live is the set of building blocks it would compose — described below with their on-chain addresses so you can check them yourself.

**For someone new to crypto:** imagine a paid API — every call costs a few cents. Today, to stop one bad actor from hammering it with spam, the service makes everyone sign up, log in, and attach their identity to every request. GhostScore asks a different question: *can a caller pay, stay anonymous, and still be held accountable?*

The idea: you prove you're a paying caller in good standing — "I've made a clean track record of past calls, and I haven't already used up my allowance this round" — **without revealing who you are**. The service can rate-limit you and refuse you if your reputation is bad, but it never learns your name, your wallet history, or links this call to your last one. No account required. Spam still gets stopped, because each anonymous call is bound to a one-time token that can't be reused.

**For the technically inclined:** GhostScore is a *composition* of three primitives that already exist and run on Solana mainnet-beta. It does not introduce new cryptography. It wires the live **x402 access gate** (a Groth16 verifier over BN254 via the `alt_bn128_pairing` syscall) together with the live **reputation gate** (a zero-knowledge proof over a Merkle commitment tree of past receipts) and the live **nullifier record** (an on-chain single-use registry). A caller pays via x402, submits one proof that satisfies *both* gates, and burns one nullifier. The payment clears, the call is authorized, and the per-round allowance is decremented — all without an account and without de-anonymizing the caller's *identity*.

***

## The one thing GhostScore does NOT hide

**GhostScore makes your *****identity***** private. It does NOT make your *****payment***** private.**

The caller still pays the x402 invoice from a normal, visible Solana wallet. That means:

| What GhostScore hides                              | What it does **NOT** hide                                |
| -------------------------------------------------- | -------------------------------------------------------- |
| *Who* you are (no account, no login)               | The **sender wallet** that paid — fully visible on-chain |
| Which past jobs/receipts built your reputation     | The **amount** paid — fully visible on-chain             |
| The link between this call and your previous calls | The fact that *a* payment happened, and when             |

So GhostScore is **identity-private only**. The privacy claim is `privacyLegs: ["identity"]` — nothing more. Anyone watching the chain can see a wallet paid the gateway; they just can't tie that wallet to a real-world identity *through GhostScore*, nor link your calls to each other via the reputation proof.

Closing the remaining leak — hiding the **sender** and the **amount** — is a **separate path**, not part of GhostScore. That path is a shielded pool or a payment relayer that breaks the link between payer and payment. It is tracked independently and is **not** assumed or implied anywhere in this design. If you need sender/amount privacy, GhostScore alone does not give it to you.

***

## What it's made of (these parts are live)

GhostScore composes three deployed Dark NULL programs. Each is **Public Beta, non-custodial, and not yet audited**, and each currently relies on a **single-party trusted setup** (one-party VK) until the multi-party ceremony finalizes. None of these caveats are optional — they carry through to GhostScore.

| Primitive                                      | What it proves / does                                                                                | Cluster      | Address                                        |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------ | ---------------------------------------------- |
| **x402 access gate** (`dark_x402_access_gate`) | A ZK proof that a caller meets an access threshold, verified on-chain                                | mainnet-beta | retired/superseded — see config (pending)      |
| **Reputation gate** (`dark_reputation_gate`)   | A ZK proof over a Merkle tree of past receipts: "≥ N clean jobs, ≥ V volume" without revealing which | mainnet-beta | `9nN7UTTT5hgKnc2LZTqr3qaLLSt5PxWUrDbpUTGYHRxp` |
| **Nullifier record** (`dark_nullifier_record`) | A single-use registry: each nullifier can be spent exactly once (double-spend rejected)              | mainnet-beta | retired/superseded — see config (pending)      |

The reputation proof reads a root from the **receipt commitment tree** (`8jC8QGiDJRRxhbPXMX5wJnGUq89xJZ2LsHMdbn2urCas`, mainnet-beta). On the live reputation gate, the proof itself is verified on-chain; the access gate verifies its proof on-chain too. GhostScore's *combining logic* — the part that makes a single x402 call require both proofs plus a nullifier burn, with per-round rate-limiting — is what remains **in design**.

> **Verification caveat to carry forward:** in the broader Dark NULL stack, some checks run **off-chain in the gateway** before the on-chain step (for example, KVAC-style credential checks). GhostScore's rate-limit accounting per round is expected to follow that pattern — gateway-side bookkeeping plus the on-chain nullifier as the hard, public anti-replay anchor. Treat any "verified" claim as on-chain only where an address and a transaction back it.

***

## How a GhostScore call would flow (design)

```mermaid
sequenceDiagram
    participant C as Caller (anonymous identity,<br/>visible wallet)
    participant G as Gateway (x402)
    participant AG as Access gate (live)
    participant RG as Reputation gate (live)
    participant NR as Nullifier record (live)

    C->>G: Request paid endpoint
    G-->>C: 402 Payment Required (price + proof challenge)
    C->>C: Build proof: access threshold + reputation<br/>(over receipt tree) + fresh nullifier
    C->>G: Pay x402 (from VISIBLE wallet) + submit proof
    Note over G: amount + sender are public —<br/>only IDENTITY is private
    G->>AG: Verify access proof (on-chain)
    G->>RG: Verify reputation proof (on-chain)
    G->>NR: Burn nullifier (single-use)
    NR-->>G: OK / REJECTED if already spent
    G-->>C: 200 Authorized (rate-limit slot consumed)
```

The nullifier is what makes anonymity *accountable*: it is derived so that a caller can spend only a bounded number per round. Reuse is rejected on-chain (the live nullifier record returns a double-spend error — `Custom(10)` — on replay). So an anonymous caller can be throttled and excluded for bad reputation **without** ever attaching an identity to the request.

***

## Why compose instead of build new

Every cryptographic part GhostScore needs is already running and already adversarially exercised on devnet (forged, tampered, replayed, and zero-proof inputs all rejected) before reaching mainnet-beta. GhostScore adds **no new circuit and no new trust assumption** — it is wiring, a challenge format, and rate-limit bookkeeping on top of live primitives. That is deliberate: the smaller the new surface, the less there is to get wrong.

What's genuinely new in GhostScore is the *policy*: requiring both proofs plus a nullifier burn for a single paid call, and defining the per-round allowance. That policy is the design work that remains.

***

## Limits

* **Identity-private only.** Sender wallet and amount stay public.
* **Single-party trusted setup.** The verification keys come from a one-party setup until the multi-party ceremony finalizes. Until then, soundness rests on that single party having discarded its toxic waste.
* **Not built.** GhostScore's combining logic, challenge format, and rate-limit accounting are unimplemented. No GhostScore program is deployed.
* **Off-chain steps exist.** Rate-limit accounting is expected to be gateway-side; only the nullifier burn and the two proof verifications are on-chain anchors.
* **Upgradeable.** The underlying programs are deployed with an upgrade authority; their behavior can change.
* **Public Beta, non-custodial, not yet audited.**

***

## Status

* **In design (not built, not deployed):** GhostScore itself — the composition that turns the three primitives into one anonymous-but-rate-limited paid x402 call, the proof challenge format, and the per-round allowance accounting.
* **Live on mainnet-beta (the parts GhostScore would compose):** x402 access gate (program id being finalized — retired/superseded — see config (pending)), reputation gate (`9nN7UTTT5hgKnc2LZTqr3qaLLSt5PxWUrDbpUTGYHRxp`), receipt commitment tree (`8jC8QGiDJRRxhbPXMX5wJnGUq89xJZ2LsHMdbn2urCas`), nullifier record (program id being finalized — retired/superseded — see config (pending)) — each Public Beta, non-custodial, **not yet audited**, single-party VK until the ceremony finalizes.
* **Devnet-proven (the reputation leg):** the full tree → root → proof → gate → nullifier flow, with forged / tampered / replayed / double-spend / zero-proof all rejected.
* **Separate path, not part of GhostScore:** sender-privacy and amount-privacy (shielded pool or relayer). GhostScore does **not** provide these.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://parad0xlabs.gitbook.io/parad0xlabs-docs/dark-null-protocol-zk-privacy-and-identity/ghostscore.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.