FinTech · Consumer rights · Anti-social-credit · Data sovereignty
A replacement for credit bureaus and social-credit systems.
No central scorer. No single database that can leak. No
universal number that follows you forever. Instead: a
cryptographically-signed, borrower-owned history where every
potential lender computes their own view and the borrower
controls who sees what.
The two problems, one shape
Credit bureaus (Equifax / Experian / TransUnion, and their global peers)
Three private companies hold the financial-reputation destinies
of hundreds of millions of people. The status-quo is well-
documented to be broken:
Errors are rampant. FTC studies find 20–25% of credit
reports contain errors; ~5% contain errors significant
enough to cause loan denial. Correcting them takes 30–180
days of disputes, and bureaus often fail to investigate at
all, merely forwarding the dispute to the lender who made
the claim.
Breaches are catastrophic. The 2017 Equifax breach
exposed SSNs, birthdates, addresses, and credit details of
147 million Americans. A centralized database is a
centralized target.
Opacity. The FICO scoring formula is proprietary.
VantageScore is proprietary. Consumers can’t replicate the
calculation. “Why was I denied?” is answered with a
boilerplate reason code, not the actual math.
Thin-file exclusion. Young adults, immigrants, the
underbanked, and anyone who avoids credit cards has no
score, and no access to mainstream credit, because the
bureau data model doesn’t recognize alternative indicators
of creditworthiness.
You don’t own the data. Credit bureaus gather information
about you without consent, sell it, and you have no
mechanism to opt out of the system.
Universal score. The same 720 follows you to the
mortgage lender, the car dealer, the apartment landlord,
the business-loan underwriter. Each has very different risk
models, but the score doesn’t know that.
Gaming. “Authorized user” scams, credit-repair
manipulators, and thin-to-thick-file tricks exist because
the scoring is formulaic and gameable.
Social-credit systems (state-operated reputation)
Some jurisdictions have experimented with state-run reputation
systems that aggregate financial, legal, behavioral, and social
data into a single score that gates access to travel, loans,
jobs, school admissions, and more.
Even where critics of these systems and proponents disagree on
whether they “work,” both sides agree on the structural risks:
Concentration of judgment. A single authority decides what
is “good citizenship” and what is not. Dissent becomes a score
penalty.
Irreversible effects. A low score can lock someone out
of public services with no clear path to rehabilitate.
Behavioral drift. Citizens self-censor because anything
might affect the score.
Due process vacuum. Appeals and dispute mechanisms are
ad hoc; the algorithm is the judge.
Discriminatory aggregation. Political activity, social
associations, religious practice, whatever the authority
considers “bad”, can accumulate into economic exclusion.
Why they share a shape
Both systems concentrate the power to judge in one entity
and produce a universal number that affects access to
opportunity. The judge has no skin in the game for your
outcomes. The number follows you without your consent. Fixing
errors means petitioning the judge.
The root problem is architectural: centralized judgment
applied to an entire population.
The Quidnug alternative: relational trust + signed history
In Quidnug, there is no score. There is:
A history of signed events attached to the subject (the
borrower/citizen): loans taken, payments made, defaults,
renegotiations, alternative-data attestations.
Trust edges from lenders/attesters to the subject in
specific domains: credit.mortgage.us, credit.auto-loan.us,
credit.small-business.consumer-goods, etc.
Each potential counterparty computes their own evaluation
using their own trust graph. Lender A’s view of a borrower
might be 0.85; Lender B’s view of the same borrower might be
0.60; neither is “the score”, both are correct from each
lender’s perspective.
The subject owns their history. They control who sees it.
Lenders build reputation by their own accuracy; a lender who
files false defaults finds other lenders devaluing their
attestations. Government observers can watch public events but
have no protocol authority to impose a universal score.
Mapping the problems to Quidnug primitives
Problem
Quidnug primitive
”Bureau is a central point of failure”
No bureau. Subject’s quid is the canonical id.
”Errors take months to fix”
Dispute event on-chain; visible to all counterparties instantly.
”I don’t own my data”
Subject’s quid + borrower-controlled encryption keys
”One score everywhere”
Per-domain relational trust; different views per lender
”Thin-file exclusion”
Alternative data sources (utilities, rent) as first-class signers
”Opaque scoring formula”
Each lender’s algorithm is their own; consumers can run their own.
”Social-credit concentration”
No protocol authority to issue a universal score
”Data breach exposure”
Distributed + encrypted off-chain payloads
”Lender defamation”
Dispute + lender reputation via consumer trust
”Lender collusion (fake credit)“
Cross-lender trust means colluders need to trick everyone
Core design
Quid types
Quid type
Owned by
Example
Subject
The individual / business (BYOQ)
subject-alice-chen-xyz
Lender
A financial institution
lender-chase-bank
Alt-data source
Utility, landlord, employer
utility-con-edison-nyc
Identity verifier
KYC provider / government
verifier-dmv-texas
Dispute arbiter
Voluntary mediator (CFPB-style, private)
arbiter-consumer-financial-watch
Guarantor
A party that co-signs / underwrites
guarantor-parent-bob-chen
All are regular Quidnug quids. What distinguishes them is the
domains they operate in and the trust edges others have issued
to them.
Domain hierarchy
credit (top-level)
├── credit.reports (generic credit-event stream)
│
├── credit.mortgage.<country>
├── credit.auto-loan.<country>
├── credit.personal-loan.<country>
├── credit.small-business.<country>
├── credit.credit-card.<country>
├── credit.student-loan.<country>
│
├── credit.alternative-data.utilities
├── credit.alternative-data.rent
├── credit.alternative-data.employment
│
├── credit.disputes
│
└── credit.identity-verification
Each lender / attester / verifier operates in the domains where
they have legitimate authority. A utility company signs events
in credit.alternative-data.utilities but not in
credit.mortgage.us.
The three things that replace a credit bureau
1. Credit events (the “history”)
Every financial event between a subject and a counterparty is a
signed event on the subject’s event stream. The on-chain record
carries only metadata; the sensitive details are encrypted
off-chain.
{
"subjectId": "subject-alice-chen-xyz",
"subjectType": "QUID",
"eventType": "credit.loan.originated",
"payload": {
"counterparty": "lender-chase-bank",
"category": "auto-loan",
"principalBand": "20k-30k", // coarse public bucket
"termMonths": 60,
"originationDate": 1713400000,
"detailCID": "bafy...", // encrypted blob, IPFS
"detailHash": "<sha256>", // binds encrypted blob
"accessGrantPolicy": "subject-approved-only"
},
"signer": "lender-chase-bank"
}
Subsequent events on the same subject’s stream:
credit.loan.payment-received (signed by lender)
credit.loan.payment-late (signed by lender, within dispute window)
credit.loan.default-declared (signed by lender, with dispute window)
credit.loan.restructured (signed by lender + subject)
credit.loan.paid-off (signed by lender)
credit.dispute.opened (signed by subject)
credit.dispute.resolved (signed by subject + lender)
credit.guarantor.cosigned (signed by guarantor)
Each event is append-only, signed by its actor, and
time-ordered. Over years, a subject accumulates a rich history.
2. Trust edges (the “score inputs”)
After each completed credit relationship, the lender issues a
trust edge to the subject in the relevant domain:
{
"truster": "lender-chase-bank",
"trustee": "subject-alice-chen-xyz",
"trustLevel": 0.92,
"domain": "credit.auto-loan.us",
"description": "60-month auto loan, paid as agreed, zero late payments",
"validUntil": 1776844800,
"nonce": 47
}
trustLevel reflects the lender’s view. A lender who was
paid on time + early would issue a higher level than one
who was paid late-but-eventually.
validUntil is typically 2–5 years; after that the edge
expires unless reaffirmed. Forces fresh data over ancient.
domain scopes the endorsement. A mortgage lender issuing
trust in credit.auto-loan.us doesn’t automatically endorse
the borrower for credit.mortgage.us.
nonce provides replay protection and lets the lender
update (e.g., downgrade if they later reopen a claim).
Alternative-data sources issue the same kinds of edges in
their own domains:
3. Per-lender relational trust evaluation (the “score”)
When a prospective lender evaluates an applicant, they run
their own relational-trust computation:
Chase-Auto-Lending: evaluating Alice for a new auto loan.
Direct history:
Chase ──0.92──► Alice (prior auto loan, paid as agreed)
→ direct trust: 0.92 (strongest signal)
Transitive history:
Wells-Fargo ──0.85──► Alice (mortgage, paid)
Capital-One ──0.80──► Alice (credit card, paid)
Chase already trusts Wells-Fargo and Capital-One as credible
lenders (the industry-peer trust graph).
Chase ──0.9──► Wells-Fargo
Chase ──0.9──► Capital-One
Transitive trust via Wells-Fargo: 0.9 × 0.85 = 0.765
Transitive trust via Capital-One: 0.9 × 0.80 = 0.72
Alternative-data:
Con-Edison ──0.88──► Alice
Chase trusts Con-Edison in utilities-payment domain at 0.7.
Transitive: 0.7 × 0.88 = 0.616
Aggregation (Chase's own formula):
max of direct/transitive = 0.92
sum of alt-data reinforcement = +0.05
Final: 0.97
Chase's decision: approve at standard rate.
Another lender, say a new fintech startup, runs a different
formula and gets a different number. That’s fine. There’s no
“right” number, there’s each lender’s judgment, made with
their own trust graph and their own risk tolerance.
Privacy model: what’s on-chain, what’s off-chain
Credit history is sensitive. Quidnug’s public chain is, well,
public. The design balances these:
On-chain (public, auditable)
Subject’s quid (public key only)
Event type (credit.loan.originated, etc.)
Counterparty identity
Coarse metadata: category, principal-band (e.g., “20k-30k”
not “$23,451”), term length, origination date
Hash of the encrypted detail blob
IPFS CID of the encrypted blob
Trust edges (truster → trustee + level + domain)
Dispute events
This level of public visibility is deliberately similar to
what lenders already learn from credit reports: “this person
has an auto loan with Chase from 2024.” What’s NOT public:
the exact principal, rate, payment amounts, etc.
Off-chain (encrypted, subject-controlled)
Exact principal amount
Interest rate and terms
Monthly payment amount
Specific payment dates and amounts
Notes / memos from either party
Correspondence / dispute details
Stored in IPFS (or S3, or any blob store) as JSON/CBOR
encrypted with a symmetric key. The decryption key lives on
the subject’s device.
How a lender accesses the encrypted details
1. Subject grants access to a specific lender:
- Generates an ephemeral encryption key for the lender
2. Lender decrypts the key with their own private key.
3. Lender fetches the encrypted blobs from IPFS.
4. Lender decrypts with the subject-provided key.
5. Now lender has full detail. They verify hashes match.
6. After validUntil, lender re-requests access.
Key property: The subject grants access to specific lenders
for specific scopes and time windows. A lender can’t aggregate
data on non-customers. A “shadow bureau” (scraping the public
chain) sees only coarse metadata, not enough to reconstruct a
person’s financial life.
The social-credit defense
For social-credit prevention specifically, this privacy model
is critical:
A government observer can see “Alice took out loans” but not
the amounts, terms, or personal details.
The government can’t unilaterally aggregate. They’d have to
get Alice’s explicit access grants, which she controls.
Even if a government compels disclosure from individual
lenders, each lender only has the sliver of history involving
them, no single entity has the full picture.
Replacing credit reporting, the flows
Subject onboarding (bring-your-own-quid)
Step 1. Individual generates their quid
────────────────────────────────────────
On their phone / device (no central registration required)
$ quidnug-credit generate
Your Subject Quid: subject-alice-chen-xyz
Your public key: 0x04abcd...
Your private key: saved locally (keep secure)
No SSN required. No forced enrollment.
Step 2. Identity verification (optional but useful)
Subject retains full control: they chose to engage this arbiter.
Lenders may honor the opinion or not, weighted by their own
trust in the arbiter.
Lender reputation feedback loop
A lender that files a false default or wrongfully denies a
dispute faces consequences:
Subject’s future lenders see the dispute + unresolved
status. Sophisticated lenders factor this in as noise,
but they can also see that the lender filing false claims
has a pattern.
Cross-subject pattern analysis, a lender that has many
open, subject-contested disputes has a reputation signal
visible to every other lender. Other lenders may
downgrade their trust in this lender in the inter-lender
trust graph, reducing the weight of their attestations.
Subject can revoke trust edges to the lender (e.g.,
if the subject later becomes a lender or validator in
another domain).
Arbitration records aggregate. A lender whose claims
are consistently rejected by respected arbiters has a
visible pattern.
Regulatory action. Fair-credit regulation (FCRA-equivalents)
continues to apply. The difference is that enforcement
has cryptographic evidence to work with.
Same subject quid → two lenders → two different decisions.
Both are correct per their own risk models. No central score
overruled or constrained either.
A subject compares their offers
$ quidnug-credit evaluate-offers
Subject: subject-alice-chen-xyz
Pulling offers from 5 lenders...
Chase (traditional): APPROVED at 6.5% ($23,451 / 60 mo)
Wells Fargo (traditional): APPROVED at 7.1%
Capital One (progressive): APPROVED at 5.8%
LendFin (alt-data-heavy): APPROVED at 5.2%
TraditionalOnly: DECLINED (thin file)
Best offer: LendFin at 5.2%.
Different lenders value different signals. The subject
benefits from competition and from bringing their own
alternative data.
Specific social-credit prevention measures
Beyond the structural “no central scorer,” the design
includes specific protections:
1. No “total citizen” domain
The domain hierarchy is intentionally bounded to credit.*.
There is no citizenship.* or trustworthiness.* top-level
domain. The protocol doesn’t provide a natural home for a
“citizen trust score.” A government attempting to create one
would have to define a new domain, and individual lenders
would have to voluntarily accept endorsements from it, which
most wouldn’t if it carries political weight.
2. Per-domain scoping enforced
A lender’s trust edge in credit.auto-loan.us does NOT
automatically count in credit.mortgage.us or any other
domain. Each evaluator chooses which domains’ edges are
relevant to their decision. There’s no aggregated “overall
score.”
3. Subject-owned data access
If a government tries to mandate that all lenders publish every
customer’s full history in the clear, the subject’s access-grant
mechanism breaks that: encrypted details require the subject’s
key. A mandate would have to compel subjects individually,
which is a much harder political project than mandating
centralized bureaus.
4. Multiple independent verifiers
A government requiring its own verifier to be used is met
with subject choice: subjects can use multiple verifiers,
and lenders can accept whichever ones they trust. No monopoly
on identity.
5. Political speech does not touch credit.*
The design domain is financial-creditworthiness. A speech act
on social media is not a credit.* event. Even if a state
tried to shoehorn political behavior into credit domains (via
a new “social-behavior” attester), lenders (and subjects) can
simply refuse to honor that attester’s signatures.
6. Voluntary participation
Nothing in the protocol forces a subject to register. A person
can go through life without a Subject Quid. They simply can’t
get credit from lenders that require one. Compare to current
social-credit systems where participation is mandatory.
7. No chain-level consequence enforcement
The protocol records signed events and trust edges. It does not
enforce consequences (e.g., “this person can’t buy train
tickets”). Any consequence is enforced by individual
counterparties, who choose whether to honor a given endorser’s
judgment. A coordinated exclusion attempt requires many
independent actors to cooperate, which gives dissenters room
to find refuge in non-cooperating lenders / markets.
Data sovereignty and portability
The subject’s quid is theirs
A subject migrating to a different country takes their quid
with them. Their signed history is portable; foreign lenders
can evaluate (weighting their trust in the attesters, which
may be lower for foreign ones, but the data exists).
Guardian recovery
A subject who loses their device / private key uses guardian
recovery (QDP-0002) to re-establish. Their history remains
intact; only the key changes.
Right to be forgotten
A subject can:
Rotate their quid (old history now associated with a
retired identity).
Revoke future access grants (existing cached data is out
of their control but no new queries).
Require lenders to emit a credit.right-to-delete
acknowledgment in jurisdictions where GDPR / CCPA apply.
The design doesn’t prevent regulations from being
enforceable; it makes them enforceable cryptographically
(lenders’ compliance is visible on-chain).
Key Quidnug features used
Bring-your-own-quid, subject owns identity.
Event streams, credit history on subject’s stream.
Trust edges with validUntil, lender endorsements expire.
credit_evaluate.py, pure per-lender evaluator over the
subject’s event stream: untrusted-attester filter,
subject-dispute discount, alt-data lift, category filter.
credit_evaluate_test.py, 11 pytest cases.
demo.py, nine-step end-to-end flow showing three
different lenders reaching different verdicts on the same
subject, a fraudulent-default scenario, and the
subject-filed dispute that neutralizes it.
Terminal window
cdexamples/decentralized-credit-reputation
pythondemo.py
Related
../elections/, similar BYOQ + cryptographic-privacy pattern
Comparison with prior decentralized-credit attempts
Attempt
Design differences
Blockchain credit scoring (various)
Usually produce a single number (just moving the bureau on-chain). Quidnug refuses to produce a universal score.
Self-sovereign identity (SSI)
Credential-based (“you have a degree”); doesn’t model credit history and payment events as first-class primitives. Quidnug does.
DeFi credit (Aave, Compound)
Over-collateralized, doesn’t solve the uncollateralized trust problem. Quidnug models actual repayment history.
Credit unions
Closer in spirit (member-owned) but still centrally scored. Quidnug removes even the member-owned central scorer.
Quidnug differs from all of these by combining: (a) relational
trust (no universal score), (b) rich signed event streams
(detailed payment history), (c) per-domain scoping, (d)
subject-controlled privacy, (e) guardian-recoverable identity.
No existing system has all five.
Architecture
Data model, components, sequence diagrams.
Architecture: Decentralized Credit & Reputation
Data model, domain hierarchy, privacy mechanism, and component
breakdown for a Quidnug-based credit system.
Node roles
Node type
Operator
Function
Subject wallet
Individual / business
Generates quid, manages keys, grants access
Lender node
Bank, fintech, private lender
Submits events, runs own trust computation
Alt-data publisher
Utility, landlord, employer
Publishes monthly payment attestations
Identity verifier node
DMV, KYC provider
Issues verification trust edges
Dispute arbiter node
Voluntary third party
Publishes opinions on disputes
Observer node (r/o)
Regulator, research, consumer advocacy
Reads public chain for analytics
Subject wallet is typically a mobile app backed by key
management (secure enclave on iOS/Android). Lender nodes are
full Quidnug nodes. Observer nodes are read-only Quidnug
nodes.
Cryptographic primitives
Primitive
Used for
ECDSA P-256 (native)
All identity, event, trust-edge signatures
SHA-256
Quid IDs, event hashes, blob integrity
ECIES (EC P-256)
Encrypting access-grant keys to specific lenders
AES-256-GCM
Encrypting detail blobs
IPFS CID (sha256 default)
Off-chain payload addressing
HMAC-SHA256 (existing Quidnug)
Inter-node authentication
ECIES is a well-established standard and can be layered on
Quidnug’s existing ECDSA keys. A subject’s single keypair can
be used for both signing (Quidnug-native) and encryption (ECIES)
with standard key-derivation.
├── credit.inter-lender-trust (lenders endorsing each other)
│
└── credit.arbiter-trust (subjects' trust in arbiters)
Cross-domain trust
Some trust is meaningful across domains. A prospective mortgage
lender reviewing a subject typically cares about:
Direct credit.mortgage.* history (highest weight)
Indirect credit.auto-loan.* and credit.personal-loan.*
as indicators of repayment behavior (lower weight)
Alt-data (credit.alternative-data.*) as supporting signal
The cross-domain weighting is the lender’s choice. Some
lenders cross-count heavily; others don’t. There’s no protocol
mandate.
Jurisdiction scoping
Domains include country code because regulatory regimes differ.
A US lender’s endorsement in credit.auto-loan.us has
different legal meaning than an endorsement in
credit.auto-loan.eu. Cross-border evaluation is possible
(trust edges from foreign lenders are first-class) but lenders
weight them per their own policies.
Quid schemas
Subject Quid
type SubjectIdentity struct {
QuidIDstring// sha256 of public key, 16 hex
PublicKey []byte// ECDSA P-256
Creatorstring// self (BYOQ)
UpdateNonceint64
Attributesstruct {
// Deliberately minimal on-chain.
// Identity facts are represented by signed trust edges
// from verifiers, not embedded here.
CreatedAtint64
}
}
No SSN, no name, no address on-chain. All those are off-chain
in verifiers’ systems and in encrypted blobs.
Off-chain blob (stored in IPFS or equivalent, addressed by CID):
{
"blobVersion": 1,
"encryptionAlgorithm": "AES-256-GCM",
"detail": {
"exactPrincipal": "23451.00",
"annualRate": "5.74%",
"monthlyPayment": "450.33",
"paymentSchedule": [ ... ],
"collateral": "...",
"borrowerAddress": "...",
"agreement": "<hash of full contract>",
"internalNotes": "..."
}
}
The whole blob is encrypted with a random symmetric key. The
CID addresses the encrypted bytes.
Access grant mechanism
The symmetric key is distributed to authorized parties via
ECIES-encrypted access grants:
Subject knows the symmetric key (they approved the event,
they have a copy).
When the subject wants to share with a lender:
Generate an ephemeral ECDH keypair.
Compute shared secret with the lender’s public key.
Derive a key-encryption key (KEK).
Encrypt the symmetric key with the KEK.
Publish the encrypted key + ephemeral public point as an
access-grant event.
Lender receives the access grant:
Compute the same shared secret using their private key +
the ephemeral public point.
Derive the KEK.
Decrypt the symmetric key.
Fetch the blob from IPFS. Decrypt. Verify hash matches.
What can a passive observer see?
The public chain reveals:
“Subject X has a credit event of type credit.loan.originated
with counterparty Chase on date D, in category auto-loan,
principal band 20k-30k, term 60 months”
“Subject X paid on time 58 of 60 months; 2 late payments of ≤10 days”
(aggregated in the final loan.paid-off event’s summary)
Trust edge: Chase trusts Subject X at 0.88 for 3 years
What the public chain does NOT reveal:
Exact principal
Interest rate
Exact payment amounts
Personal details of subject
Reason for any late payment
Details of any dispute
Is this level of public info enough to cause concern? That’s a
design choice. For stronger privacy, a jurisdiction can deploy
with:
Commitment-only events, even the counterparty is hidden
on-chain; only a commitment is public. Full data (including
counterparty identity) is in the encrypted blob.
Zero-knowledge proofs, for computed evaluations (“this
subject’s on-time payment ratio ≥ 90%”) without revealing
the underlying events.
These would be QDPs in their own right. The baseline design
gives privacy comparable to what current credit reports show
a lender, while enabling far more granular consumer control.
Trust computation details
Direct trust
A direct trust edge from a specific counterparty in the queried
domain:
query: evaluate Alice for an auto loan, I am lender Chase
edges: Chase --0.92--> Alice in credit.auto-loan.us (found)
direct trust = 0.92
Transitive trust
Through other lenders Chase trusts:
edges:
Chase ---0.9----> Wells-Fargo in credit.inter-lender-trust
Chase ---0.85---> Capital-One in credit.inter-lender-trust
Wells-Fargo ---0.85---> Alice in credit.auto-loan.us
Capital-One ---0.80---> Alice in credit.auto-loan.us
The lender writes this logic once. Queries Quidnug for all
edges + events. Computes. Decides. Independent from any bureau.
Anti-collusion trust math
A subject cannot simply pay a friendly “fake lender” for a
glowing endorsement because the fake lender’s edges are only
worth as much as other lenders trust the fake lender.
Fake lender needs inter-lender trust to be useful
To gain inter-lender trust, it needs real loan history with
subjects other lenders trust
Building this trust takes years and real-capital exposure
At scale, fraud rings are detectable (same subjects
endorsing each other with no external borrowing activity)
This is structurally much harder than the current system,
where a lender can simply file false data to a bureau.
100M subjects × 100 events/year = 10B events/year ≈ 300M/day
Event volume is large but not unusual for a blockchain system.
Push gossip’s producer rate limits cap per-lender spam.
Trust-graph size: 100M subjects × avg 10 inter-lender trust
edges = 1B edges. Handleable with good indexing. Most queries
are per-subject so they don’t touch the full graph at once.
"correctionReason":"Bank processing delay confirmed; payment was timely",
"newFacts":{
"onTime":true,
"daysLate":0
}
},
"creator":"lender-chase-bank",
"signature":"<lender signs>"
}'
When future evaluators read the history, they see the late-
payment event + subject’s dispute + lender’s response + the
correction. The correction supersedes; evaluators counting the
history treat this payment as on-time.
4d. Escalation to arbiter
If subject disagrees with lender’s denial:
Terminal window
# Subject engages an arbiter (arbiter's fee handled off-chain)
After recovery, Alice’s credit history is still linked to her
Subject Quid. Lenders re-query; they see the same history.
Access grants issued under the old epoch are invalidated
(lenders need new access grants after rotation). This is a
security property: stolen access grants don’t survive a
compromise-rotation.
9. Testing
funcTestCredit_BasicEvaluation(t*testing.T) {
// Subject has: 1 paid auto loan, 3 years utility history
// Lender with direct trust in utility, no direct in subject
Subject’s credit history integrity, the cryptographic
record of their financial behavior.
Subject’s private key + encryption key, controls
identity and data access.
Lender’s signing authority, attestations carry their
reputation.
Consumer financial autonomy, ability to participate
without coercion.
Absence of centralized scoring, the architectural
property that prevents social-credit concentration.
Attacker inventory
Attacker
Capability
Primary goal
Compromised subject key
Subject’s signing key
Open fraudulent credit in subject’s name
Identity thief
SSN / ID + ability to create fake quid
Open credit accounts impersonating subject
Collusive lender ring
Real lenders, cooperative fraud
Fake credit histories
Defamatory lender
Real lender, wants to harm borrower
File false defaults
Shadow-bureau aggregator
Public chain observer + ML
Rebuild a central score from public metadata
State actor, social credit
Legal/political authority
Impose universal citizen score
Employer
Has leverage over subject
Compel subject to reveal full history
Coercer / abuser
Personal relationship with subject
Compel subject to share access grants
Compromised verifier
Valid identity-verifier key
Enable identity theft at scale
Breach of lender’s DB
Off-chain data
Disclose details despite encryption
Lender employees
Legitimate read access to customer data
Exfiltrate for profit
Threats and mitigations
Category A: Identity and impersonation
A1. Stolen subject quid private key
Attack. Attacker obtains the subject’s private key and
opens credit in their name.
Mitigations.
Lender identity verification, lenders accept new
applications only for subjects with trust edges from
verifiers the lender trusts (DMV, bank-KYC). Attacker with
stolen key but no matching verifier endorsement fails.
Multi-factor at origination, lender’s off-chain flow
(call, email confirm, biometric) bounds the damage.
Subject monitoring, subject sees any new credit events
on their stream. Push gossip propagates within seconds; a
watching wallet app alerts immediately. Subject can
rotate via guardian recovery within hours.
Guardian recovery, subject rotates their quid to a
new key; old key’s future signatures are invalid. Lender
accepts the new epoch for new applications.
Residual risk. Small window between key theft and subject
detection. Bounded by monitoring diligence; mitigated by
standard fraud-detection overlays (same as current systems).
A2. Synthetic identity, attacker creates fake quid + impersonates real person
Attack. Attacker generates a fresh quid and tries to
establish an identity as if they were some real person.
Mitigations.
Verifier trust edges are the gate. Identity verifiers
(DMV, KYC providers) do their existing real-world
verification. Attacker can’t synthesize a legit verifier
endorsement without passing their checks.
Cross-verifier consistency: multiple verifiers should have
consistent views. A synthetic identity verified by one
verifier but not any other is suspicious.
Existing ID-verification industry continues to operate;
Quidnug makes their endorsements cryptographically
portable.
Category B: Lender misconduct
B1. False-default defamation
Attack. Lender files a late-payment or default event that
the subject disputes as false.
Mitigations.
Dispute mechanism, subject’s counter-event is visible
alongside the lender’s claim. Future evaluators see both.
Arbiter opinions, independent arbiter can weigh in.
Lenders with multiple arbiter-rejected claims look bad.
Cross-lender trust degradation, lenders who observe
another lender consistently over-reporting can lower their
inter-lender trust edge, reducing that lender’s attestation
weight.
Regulatory enforcement, FCRA-equivalent laws still
apply, now with cryptographic evidence trail.
Subject narrative control, dispute events let subject
document the context; future evaluators judge fairly.
B2. Hostage-taking, lender refuses to emit payoff event
Attack. Subject has paid off their loan but lender delays
or refuses to emit the paid-off event, leaving the loan
appearing open.
Mitigations.
Subject-initiated correction dispute, subject emits
credit.dispute.opened with evidence of final payment.
Future evaluators see the dispute.
Arbiter engagement, independent arbiter can verify and
issue an opinion.
Bank-regulator involvement, regulatory systems still
exist and can mandate lender compliance.
Switching lenders, subject can route future business
away from the hostile lender, and lenders that see this
pattern downgrade their trust in the original lender.
B3. Lender collusion ring, fake endorsements
Attack. Lender A and Lender B (controlled by same fraudster)
issue fake trust edges back and forth endorsing fraudulent
subjects. The goal: manufacture creditworthiness so those
subjects can defraud legitimate Lender C.
Mitigations.
Inter-lender trust, Lender C’s evaluation of a
subject’s endorsers is based on C’s own trust in the
endorsers. Fake lenders with no legitimate banking activity
have minimal inter-lender trust. Their endorsements carry
little weight.
Regulatory registration, real lenders have OCC / FDIC
/ regulatory numbers. Endorsements from unregistered “lenders”
are filterable.
Pattern detection, a ring of mutually-endorsing new
entities without any external activity is a statistical
anomaly. Research / consumer-protection orgs can publish
warning events about such rings.
Regulator observation, regulators have free public read
access to the chain. Regulatory action possible.
Residual risk. Well-disguised collusion at scale is
possible but harder than gaming today’s bureau-based system.
B4. Hidden rate discrimination
Attack. Lenders use trust evaluations to discriminate on
prohibited categories (race, age, etc.).
Mitigations.
Protected categories are not on-chain. Quidnug chain
doesn’t store name, race, address, DOB. Discrimination based
on these requires the lender accessing off-chain data, same
as today.
Public pattern analysis, regulators can observe
approval patterns per-lender (approve/decline rates by
inferable demographics). Same existing regulatory oversight
mechanism.
Lender’s algorithm is their own, but the inputs are on
the chain. Regulators can demand the algorithm and replay
decisions to audit discrimination.
Category C: Privacy and data-broker threats
C1. Shadow-bureau aggregator
Attack. Entity scrapes the public chain, builds a
database of subjects’ coarse credit histories, sells it as a
“traditional credit report” service.
Mitigations.
Public chain contains only coarse metadata. Exact
amounts, rates, payment details are encrypted. Even with
perfect scraping, the scraper gets “subject had a loan,
type, approx size, on-time or not”, already comparable to
what bureaus publish publicly.
Subject can use multiple quids, a privacy-conscious
subject can maintain separate quids for different credit
relationships, making cross-relationship correlation
harder.
Legal regime, shadow bureaus compiling records without
consumer consent fall under existing FCRA / GDPR
frameworks.
Residual risk. A competent scraper can produce a “summary
report” service. Less detailed than current bureaus, but some
reconstruction is possible. Fundamental to any public-history
system; solution is stronger cryptographic privacy if needed
(ZK proofs; future QDP).
C2. Coerced access grants
Attack. Employer / abuser / landlord requires subject to
share full credit history as a condition.
Mitigations.
Partial access grants, subject can share only specific
scopes. Employer asking for “alt-data.rent” history doesn’t
get all loan data.
Time-bounded access, 30-day access grant expires;
coercer has to keep re-coercing.
Multiple quids, subject can maintain a “professional
quid” with limited history and a “full quid” kept private.
Legal protections, jurisdictions that prohibit
employer credit checks continue to do so; the protocol
doesn’t enable new coercion pathways that weren’t possible
before.
C3. Detail-blob leak at lender
Attack. Lender stores detail blob in plaintext on their
server; server is breached.
Mitigations.
Design requires lender keeps blob encrypted at rest.
Access grant provides a key; lender’s servers should store
the encrypted blob plus the key (or decrypt on-demand and
discard).
Lender security practices continue to apply. This is
the same problem as any lender holding customer data.
Scope-limited grants, lender only receives the detail
for specific scopes they need. Leak exposes only granted
scope.
Category D: Social-credit concentration attempts
D1. State mandates a “national citizen trust score”
Attack. Government declares that all lenders must accept
endorsements from a state-operated scoring agency and weight
them heavily.
Mitigations (structural / operational).
Protocol refuses to produce a universal score. State
can create a quid and issue endorsements, but can’t force
private lenders to weight those endorsements.
Domain separation, a “citizen-trust” domain created by
the state is a new domain. Lenders opt in per jurisdiction
and legal requirement. Voluntary adherence is the check.
Parallel markets emerge, if state-score-accepting
lenders become the only option, non-state-score lenders
(in friendlier jurisdictions, or informal / alternative
markets) become a pressure valve.
Residual risk. In fully-authoritarian regimes, the
government can pass laws forcing participation. Quidnug
can’t override law; it provides architectural defense for
everywhere the law doesn’t reach.
D2. Political-behavior attestations
Attack. State or private actor publishes
political-loyalty-score trust edges and pressures lenders
to use them.
Mitigations.
Lenders can refuse, there’s no protocol requirement to
honor any particular attester’s edges.
Regulatory environment, anti-discrimination law
typically prohibits lending decisions based on political
affiliation. Publishing an edge doesn’t mean lenders can
lawfully use it.
Subject awareness, subjects can see what attesters are
issuing about them and challenge via disputes.
D3. Cross-domain score aggregation
Attack. An aggregator takes trust edges from
credit.mortgage.us, credit.auto-loan.us, etc., and
publishes a composite “general creditworthiness” score.
Mitigations.
Lenders evaluate independently. An aggregator’s
composite is meaningful only if lenders choose to use it,
same pattern as the social-credit defense.
Competition in aggregation, no monopoly; many
possible aggregators. Subjects can choose which they want
to be summarized by.
Transparency, aggregator’s formula is public (on-chain
event schemas); lenders can audit it.
Category E: Infrastructure attacks
E1. Network-level denial of service
Attack. DDoS on Quidnug nodes to prevent lenders or
subjects from querying.
Mitigations. Standard DDoS protections; distributed node
operation means multiple alternative nodes available.
E2. IPFS-dependency attacks
Attack. IPFS pinning service that holds detail blobs
goes offline or is compromised.
Mitigations.
Subject should pin their own detail blobs (via local
IPFS client or paid pinning).
Lender can also pin (for their own access durability).
Alternative storage, design is IPFS-friendly but
not IPFS-required. S3, Filecoin, Arweave, or any content-
addressable store works.
Category F: Adversarial economics
F1. Lender refuses to operate at a loss
Attack. A bad actor (sovereign or private) gains
influence over many lenders; pressures them to refuse credit
to specific demographic or political class.
Mitigations.
Market diversity, no single entity controls all
lenders. Marginalized borrowers find alternative lenders.
Community lending, informal peer-to-peer lending has
always existed; Quidnug gives it cryptographic tools.
F2. Predatory inclusion
Attack. Lender uses relational-trust data to identify
vulnerable subjects for predatory loans.
Mitigations.
Regulatory frameworks against predatory lending continue
to operate.
Subject’s dispute mechanism + visible pattern of lenders
with predatory behavior.
Consumer-advocate trust edges warning about specific
lenders.
Attack scenarios, end-to-end
Scenario 1: “Attacker wants to sabotage subject’s credit”
Required actions:
File a false-default event against subject.
Ensure subject can’t dispute (?).
Cause future lenders to weigh the event heavily.
Defenses that defeat this:
Subject sees the event via monitoring → files dispute.
Dispute is visible to future lenders.
Attacker-lender’s own reputation degrades.
Regulator/arbiter oversight.
Compared to current bureaus, the attacker needs to be an
endorsed lender to file events (regulatory barrier) AND
survive subject’s dispute + arbiter scrutiny.
Scenario 2: “Government wants to build a social-credit system”
Required actions:
Create a state-operated “citizen trust” issuer.
Compel private lenders to weight the state’s endorsements.
Compel subjects to share full history.
Defenses:
Private lenders’ algorithms are their own; legal compulsion
required and constrained by jurisdiction constitutions.
Subject access grants are discretionary; compelling every
subject is politically costly.
International lenders operate in different jurisdictions.
Civil society can publish counter-attestations.
Compared to a centralized government-operated database, the
protocol makes the authoritarian move much harder (requires
coercing many independent actors).
Scenario 3: “Thieves steal subject’s key via phishing”
Temporary suspension of new applications while subject
investigates.
Comparable to current system’s defenses against identity
theft; cryptographic guardians make recovery faster than
traditional bureau freeze / unfreeze cycles.
Not defended against (explicit limits)
Subject voluntarily shares all history under duress.
Legal regime remains the primary defense.
Regulator collusion. If all regulators coordinate to
mandate state-score usage, protocol doesn’t override.
Fundamental privacy vs. verifiability trade-off. The
public metadata (event type, counterparty, coarse band) is
inherent. Stronger privacy (ZK proofs) is future work.
Lender’s off-chain decision. Lender can deny credit
for any reason that isn’t specifically illegal. Protocol
supports the decision; doesn’t mandate it.
Full anonymization. The protocol preserves
pseudonymity (quids), not full anonymity. State-level
adversaries with enough data can correlate.
Irrational lenders. A lender willing to lose money can
ignore any trust signal and lend anyway. Market
competition is the discipline.
Monitoring
Public observability / metrics:
Metric
Alert condition / purpose
Subject dispute rate per lender
> baseline: pattern of defamation
Lender approval-vs-denial rate by inferable demographic
> threshold: possible discrimination
Trust edges issued between new quids
> threshold: possible collusion
Arbiter opinions issued per lender per month
> threshold: lender misconduct
Subject-lender disputes unresolved past 90 days
> threshold: lender compliance issue
Cross-lender trust degradation events
any
Incident response
Playbooks (excerpts):
Subject reports identity theft.
Emit subject.identity-compromised event on subject’s stream.
Guardian-recovery rotation of subject quid.
All pending applications halted at new-epoch.
Lender notifications via push gossip.
Lender has pattern of disputed claims.
Consumer-advocate org publishes public warning event.
Other lenders downgrade inter-lender trust edges.
Regulator can issue a formal enforcement event.
Attempted state-credit-score rollout.
Civil-society orgs publish counter-attestations.
Lenders in jurisdictions with legal protections refuse
to weight it.
Subjects advised to use multi-jurisdictional quid
strategies.