FinTech · Cross-organization data sharing · Relational trust
The problem
Merchants and payment processors collectively see billions of
fraud signals per day. An attacker card-testing at Merchant A
today hits Merchant B tomorrow. Current industry attempts at
shared-fraud databases all founder on the same wall:
If I share my data, my competitors get value. If I don’t,
we’re all worse off. And if I share bad data (either by
accident or malice), I poison everyone else.
Concretely:
Visa/Mastercard fraud feeds exist but are reactive,
aggregated, and delayed. Real-time cross-merchant signal isn’t
there.
Third-party data consortiums (e.g., Sift, Signifyd
networks) require every participant to trust the central
operator, who now has the keys to a very valuable database.
Direct merchant-to-merchant sharing exists at the informal
level (private Slack channels for security leads) and at the
heavyweight level (ISACs) but with no structured trust model.
The fundamental issue is that trust in fraud reports isn’t
universal. A 500-merchant consortium will have:
A few very-high-signal reporters (large merchants with
sophisticated fraud teams).
Many medium-quality reporters.
Some noisy / adversarial / compromised accounts whose reports
should be ignored or even reversed.
A single “is this reporter trusted” toggle doesn’t capture reality.
Each consumer of a fraud signal should weight it differently.
Why Quidnug fits
This is relational trust’s natural shape. Each merchant
computes their own trust in every other merchant, based on
direct experience and transitive endorsements through mutual
business partners.
Problem
Quidnug primitive
”Do I trust signals from merchant X?”
Trust edge in fraud.signals.us-retail
”Did X actually sign this report?”
ECDSA signature on event-stream entry
”Has X been compromised and is re-playing?”
Monotonic anchor nonces
”How do I weigh a new merchant’s reports?”
Transitive trust through mutual peers
”How do signals propagate in near-real-time?”
Push gossip (QDP-0005)
“How do I bootstrap a new member?”
K-of-K snapshot (QDP-0008)
High-level architecture
Consortium
─────────────
(members run their own
Quidnug nodes, no central
operator)
┌────────────────┐ gossip ┌────────────────┐
│ Acme Retail │ ◄────────► │ BigBox Inc │
│ (Quidnug node) │ │ (Quidnug node)│
└───────┬────────┘ └────────┬───────┘
│ │
│ gossip │ gossip
│ │
▼ ▼
┌────────────────┐ ┌────────────────┐
│ Fin-Tech #1 │ ◄────────► │ Bank.com │
│ (Quidnug node) │ gossip │ (Quidnug node)│
└────────────────┘ └────────────────┘
Each member emits fraud signals as events
into a shared "fraud.signals.us-retail" domain.
Each member computes trust FROM THEIR OWN PERSPECTIVE
when evaluating a signal.
Data model
Quids
One per member organization (Acme, BigBox, Fin-Tech #1, etc.).
Optionally, sub-quids per fraud-team analyst (so compromises are
contained to one analyst’s key).
Domain
fraud.signals.us-retail (main).
Sub-domains by vertical: fraud.signals.us-retail.apparel,
.electronics, .travel.
Members subscribe to subdomains relevant to them.
Signal as event stream entry
Every fraud signal is an event on a subject quid that represents
the flagged entity (card fingerprint, IP, device ID, email
pattern). Example:
{
"type": "EVENT",
"subjectId": "card-fp-8f3a9b...",
"subjectType": "QUID",
"eventType": "fraud.signal.card-testing",
"payload": {
"reporter": "acme-retail",
"severity": 0.9,
"evidence": {
"pattern": "multiple-CVV-retries",
"window": "5min",
"observedAt": 1713400000
},
"actionTaken": "decline",
"comment": "Testing stolen card numbers against $1 donations."
},
"signature": "<Acme's signature at its current epoch>"
}
Trust edges
Each member declares trust in peers they find reliable:
acme-retail ──0.9──► bigbox-inc (work with them for years)
acme-retail ──0.7──► fin-tech-1 (known good reputation)
bigbox-inc ──0.8──► newcomer-ltd (BigBox did their DD)
Now when Newcomer submits a signal, Acme (direct trust 0.3) can
also weigh through BigBox’s endorsement (0.95 × 0.8 = 0.76) and
take the max, Newcomer’s signals get effective trust 0.76 from
Acme’s perspective, not the pessimistic 0.3.
Signal consumption flow
1. Acme sees a card-testing pattern hit their checkout.
2. Acme submits a fraud signal event against the card fingerprint:
POST /api/v1/events
eventType: "fraud.signal.card-testing"
3. Push gossip (QDP-0005) propagates the event to peer nodes
within DomainGossipInterval * hops.
4. BigBox's node receives it. BigBox's fraud system polls for
new events in `fraud.signals.us-retail.*`.
5. For each received event, BigBox computes:
relTrust(bigbox-inc → reporter) in the signal's domain.
7. BigBox optionally emits their own corroborating event.
Now the card fingerprint's stream has TWO corroborating
signals, which raises the effective score for everyone
seeing both.
Counter-signals (“this wasn’t fraud”)
Recovery path for false positives. If BigBox discovers a flagged
card was actually a legitimate customer, they emit:
{
"eventType": "fraud.signal.counter",
"payload": {
"reporter": "bigbox-inc",
"counters": ["<event-id of original signal>"],
"evidence": "customer verified; purchased $2000 of verified goods"
}
}
Consumers see both the original signal and the counter, and can
make a better-informed decision. The original signal isn’t
retracted (that would let malicious reporters hide their history);
it’s complemented.
Reporter reputation management
A reporter whose signals are frequently countered by trusted
peers sees their effective incoming trust decay naturally.
Each consumer can apply their own heuristic:
effective_trust(reporter) = base_trust(reporter)
- 0.5 * fraction_countered
Publish this effective weighting via lower trust edges. Over
time, a noisy reporter gets deprioritized by the network without
any central operator making that call.
Compromised reporter detection
If Acme’s signing key is compromised and an attacker floods
fake signals (“this legitimate card is fraud”), there are
several responses:
Rate limit on the gossip layer (QDP-0005 §7), per-producer
message rate limit means one compromised member can only flood
so fast.
Counter-signal cascade, peers that see legit cards flagged
emit counter-signals, degrading the attacker’s effective
reputation.
Emergency rotation via guardian recovery, Acme’s fraud
team’s personal guardians (security team, CTO) can rotate Acme’s
key, invalidating the attacker’s signing authority.
The critical point: no central operator can be coerced into
kicking Acme off the consortium. Recovery is member-driven.
Key Quidnug features used
Relational trust in fraud.signals.us-retail, each member
has their own view, so a bad actor can’t poison universally.
Push gossip (QDP-0005), signals propagate within ~30 seconds.
Faster than polling a central feed.
Anchor nonces (QDP-0001), replay protection on signals. A
signal can’t be re-submitted twice for double-counting.
Guardian recovery (QDP-0002), if a member’s signing key is
compromised, their security team can rotate without disrupting
the consortium’s operation.
Domain hierarchy, members subscribe to vertical-specific
subdomains. An apparel retailer doesn’t need electronics-
fraud signals.
K-of-K bootstrap (QDP-0008), a new member joins by getting
snapshots of the trust graph from K existing trusted members.
Fork-block trigger (QDP-0009), when the consortium agrees
to (e.g.) require signal severity ≥ 0.5 to propagate beyond one
hop, a fork-block activates the change uniformly.
This is well within a single Quidnug node’s comfort zone. Push
gossip handles propagation; each member node processes only
signals in their subscribed subdomains.
demo.py, end-to-end flow against a live Quidnug node
exercising all four actors (bootstrapping merchants,
asymmetric trust edges, emitting signals, observer-
relative aggregate scoring).
Running:
Terminal window
cddeploy/compose && dockercomposeup-d# start local node
cdexamples/merchant-fraud-consortium
pythondemo.py
Related
../interbank-wire-authorization/,
similar consortium pattern; different threshold model (wires need
internal bank quorum; fraud signals are single-party statements
weighted per-consumer).
During the time-lock window (1h default), consortium peers can
see the rotation is pending. Their push gossip catches the
eventual commit; within minutes of commit, Acme’s old key is
no longer valid for new signals.
8. Joining as a new member
A new merchant wants to join. Four steps:
8a. Self-register identity (off-network)
Generate a keypair, build a Quidnug node, create root identity.
8b. K-of-K bootstrap from existing members
cfg:=core.DefaultBootstrapConfig()
cfg.Quorum=3
cfg.TrustedPeer=""// no operator override, strict K-of-K
// Before bootstrap, seed the trust list with public keys of
// known-good existing members (obtained out-of-band, email,
Send each member’s security team a signed self-introduction
(off-band). Members review the newcomer’s reputation,
certifications, and emit trust edges:
Terminal window
# Acme (having vetted the newcomer)
curl-XPOSThttp://localhost:8080/api/trust-d'{
"truster": "acme-retail",
"trustee": "newcomer-ltd",
"trustLevel": 0.3, /* low starting trust; grows with performance */
"domain": "fraud.signals.us-retail",
"nonce": 47,
"validUntil": <now + 90d>
}'
8d. Start emitting signals
After bootstrap and at least one inbound trust edge, the
newcomer can emit signals that will be weighted at whatever
level each peer has assigned.
../defi-oracle-network/, related
pattern where signal → price, relational trust → weighted
aggregation.
Threat model
Adversaries, assumed capabilities, mitigations.
Threat Model: Merchant Fraud Consortium
Assets
Signal accuracy, the consortium’s collective ability to
detect fraud depends on signals being truthful.
Member reputation, a member wrongly accused of a false
positive loses commercial value.
Cardholder privacy, the underlying PAN data is not
on-chain, but patterns of flagging are.
Cross-member trust graph, who trusts whom is market-
sensitive information.
Attackers
Attacker
Capability
Goal
Compromised member key
Valid signing key of one member
Flood false signals / reverse reals
Malicious joiner
Legitimate new member, bad intent
Poison the network
Competitor
Legitimate member, mixed motives
Hurt a competitor’s reputation
Fraudster
No consortium membership
Manipulate signal network
Central authority demand
Law enforcement / regulator
Access member data
Threats
T1. Compromised member emits false signals
Attack. Attacker gains control of one member’s signing key
and emits thousands of fake signals flagging legitimate cards.
Mitigation.
Relational trust, other members weigh this reporter’s
signals through their own lens. The more signals they emit,
the more are countered by trusted peers, the lower their
effective weight becomes.
Push gossip rate limit (QDP-0005 §7), per-producer token
bucket means the attacker can only emit so many signals per
minute before their forwarded traffic is rate-limited.
Counter-signal cascade, trusted peers seeing obvious
false positives emit counters, which degrade the attacker’s
effective trust.
Emergency rotation, member’s security team rotates their
signing key via guardian recovery. Old key becomes invalid
within the delay window.
Residual risk. Window of attack between compromise and
detection. Mitigated by monitoring (signal-rate anomalies,
counter-signal-volume alerts).
T2. Malicious new member
Attack. Attacker establishes a shell merchant, gets
minimal vetting, joins the consortium, and emits malicious
signals.
Mitigation.
Starting trust is low, new members typically get
trust 0.1–0.3 from existing members. Their signals have
low effective weight until they build reputation.
Transitive trust degrades, if the malicious member can’t
get a trusted peer to endorse them, their signals stay
low-weight.
Any member who vouched can revoke, trust edges are
time-limited; validUntil enforces periodic re-affirmation.
Residual risk. If the malicious actor successfully
compromises or social-engineers several existing high-trust
members into vouching, they can accumulate reputation. This
is a long-term con, detectable by auditing trust-graph
changes.
T3. False-positive weaponization
Attack. A legitimate but aggressive fraud team at Merchant
A regularly emits signals that turn out to be false positives
affecting Merchant B’s customer base.
Mitigation.
Per-consumer reputation tracking, each member can
internally compute “how often does Acme’s signals get
countered by my trusted peers?” and lower their local trust
in Acme accordingly.
Public counter-signal trail, A’s false positives
accumulate visibly in A’s signal history.
Residual risk. Not a cryptographic problem; a market-
incentive one. The transparency makes it manageable.
T4. Signal-flow correlation attack
Attack. Observer of gossip traffic tries to correlate
which members are sharing signals with which others, inferring
commercial relationships.
Mitigation.
Push gossip fanout means every member receives every
signal, not just “interested” subsets, no pairwise
correlation from gossip patterns.
Content-level correlation (who emits signals about which
cards) is inherent to the domain; consortium membership is
public by design.
Sub-domains let members scope what they emit publicly
(vertical-specific subdomains).
Residual risk. An observer with gossip-level network view
can see who emits and when. If that’s a concern, Tor-like
anonymizing relays are future work beyond Quidnug.
T5. Replay attack
Attack. Attacker captures a legit signal from Acme and
re-submits it to have signals double-counted.
Mitigation.
Dedup-first processing (QDP-0005 §6.5), message ID
dedup rejects replays in O(1) before even checking
signatures.
Per-signer anchor nonce (QDP-0001), each signal is
bound to an anchor-nonce; a replay has the same nonce,
immediately rejected.
Residual risk. None.
T6. Sybil, one person, many “members”
Attack. Attacker registers 50 shell merchants, each with
a quid, and has them mutually endorse each other to build
fake-trust graph.
Mitigation.
Out-of-band vetting, existing members don’t issue
trust edges to shell entities they don’t know. Sybils can
endorse each other all they want; without an edge from a
real member, they remain unreachable in the trust graph.
Trust edges are public, a mutual-endorsement ring is
visually obvious in the graph.
Periodic trust expiration (validUntil) forces
re-attestation, raising the ongoing cost of maintaining
sybils.
Residual risk. If a single legitimate member is compromised
and starts endorsing sybils, the ring gets a foothold. See T1.
T7. Legal / regulatory subpoena
Attack. Government serves a subpoena on the central
operator.
Mitigation.
There is no central operator. Each member holds their
own data. Subpoenas go to individual members, who can
decide with counsel.
Residual risk. Individual members can still be compelled.
But the consortium isn’t a single target.
T8. Denial of service on one member
Attack. Flood one member’s node with traffic to prevent
them from emitting / receiving signals.
Mitigation.
IP-level rate limiting on HTTP surface.
Push gossip is resilient to one-peer outage (messages
propagate through other peers).
Member’s signal consumption is not latency-sensitive
(seconds to minutes is fine).
Residual risk. Standard DoS mitigations (CDN, WAF) apply.
T9. Data poisoning via severity inflation
Attack. Attacker submits every signal with severity=1.0
to maximize disruption.
Mitigation.
Consumer-side normalization, consumers don’t have to
trust reporter-declared severity. Severity × reporter-trust
is the effective weight.
Counter-signals include a rebuttal severity, so a
counter can match and neutralize.
Residual risk. Mostly structural, not a cryptographic
problem.
T10. Consortium governance capture
Attack. A coalition of members passes a fork-block that
changes the signal-validity rules in their favor (e.g.,
lowering the counter-signal weight).
Mitigation.
2/3 quorum required for fork-block transactions (QDP-0009
§7). Capturing 2/3 of the validator set is itself a massive
Sybil attack.
MinForkNoticeBlocks = 1440 ~= 24h. Every operator sees
the change 24h before activation. Smart operators halt and
investigate suspicious forks.
Members can operator-override their node’s flag
settings, refusing to honor a controversial fork locally.
Residual risk. Majority-validator compromise is the
prerequisite.
Not defended against
Raw PII leaks, the protocol stores hashes and
patterns, but if a member wraps a full PAN in an event
payload, it’s on-chain. This is a member-application-layer
responsibility.
Collusion between multiple members, the protocol
assumes each member is their own principal. Explicit
collusion is out of scope.
Gaming the trust algorithm, the BFS-pathing with max
aggregation can be gamed by carefully structuring
endorsements. Mitigations are part of the trust-algorithm
design, not this use case.
Monitoring
Critical Prometheus metrics:
quidnug_gossip_rate_limited_total{producer=...}, a
member being rate-limited may be under attack or may be
compromised.