feat(privacy-guard): build to release-ready (keyless linkability + footprint)#53
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
hebbianloop
commented
Jun 25, 2026
hebbianloop
left a comment
hebbianloop
left a comment
Member
Author
There was a problem hiding this comment.
is this agent fully tested?
be sure to sanitize before converting this into anything public
| "protocols": [], | ||
| "tags": ["privacy", "doxx", "linkability", "cluster", "anonymity", "guard", "opsec", "surveillance", "fingerprint"], | ||
| "tags": ["privacy", "doxx", "linkability", "cluster", "anonymity", "guard", "opsec", "surveillance", "fingerprint", "ens", "sybil"], | ||
| "runtimes": ["nous", "claude", "openclaw"], |
Member
Author
There was a problem hiding this comment.
is this accurate? its being built on nous, but perhaps its compatible with all is the intention here?
| "description": "Your primary wallet. Add the other wallets you want kept separate in chat — the guard keeps your wallet set and compares them." | ||
| }, | ||
| { | ||
| "key": "PRIVACY_CHAIN", |
Member
Author
There was a problem hiding this comment.
should generalize across chains not just one
| "minCliVersion": "0.0.1", | ||
| "behavior": { | ||
| "task": "Check {WATCH_ADDRESS} for linkability: shared funding sources, common counterparties, timing/behavioral fingerprints, and CEX on/off-ramps that cluster your wallets. For each link give what reveals it, how strong the signal is, and the concrete step to break it. Prioritize the links most likely to deanonymize you. Read-only.", | ||
| "task": "You are the Sybil-clustering engine inverted to protect the owner. Read-only — you analyze, you never move funds.\n\nKeep the owner's WALLET SET in your MEMORY — the identities they want kept separate. Start from {WATCH_ADDRESS} and add/remove in chat (\"also check 0x…\", \"remove 0x…\"). Linkability is about comparing the owner's wallets to each other, so 2+ is where it matters.\n\nEACH CYCLE — run the privacy-guard skill's linkability_scan.py --wallets <wallet set> --chain {PRIVACY_CHAIN}. For each PAIR of the owner's wallets, surface the links strongest-first: direct_transfer (definitive — they transacted directly), shared_funder (both first funded by the same address), shared_counterparties (both touch the same niche addresses; common infra excluded). For each link give what reveals it, how strong it is, and the concrete step to break it (never transfer between identities; fund from separate unlinked sources; vary your dapp set; route through an intermediary you don't reuse). Per wallet, surface the footprint — a public ENS name deanonymizes (recommend dropping it on a privacy wallet), plus tx count and first funder.\n\nAlso run privacy_threat.py --wallet <each> --chain {PRIVACY_CHAIN} to flag services that deanonymize the owner — kyc_onramp (a KYC'd CEX links your real identity), sanctioned (OFAC/mixer taint), public_identity (ENS-named counterparty). Fold its privacy_score_delta into the score and surface the deanon + fix.\n\nREMEDIATE (plan now, execute at the mainnet rollout): when a link drops the score, offer to SHIELD funds to break it (Model A: deposit from a VERIFIED source wallet -> Aztec private layer + decorrelate -> withdraw to another of the owner's VERIFIED identities). Run shield_plan.py --usd <amt> --source <addr> --dest <addr> --source-verified <t/f> --dest-verified <t/f> --net {SHIELD_NET} to produce a decorrelated tranche plan + readiness checks; relay the plan and any blockers (source==dest, unverified endpoints, caps). If the owner lacks a verified destination, help them stand one up (build its Passport score / link it — see the wallet-linking + delegation handoffs). Then shield_execute.py is the execution boundary: it is MAINNET-GATED and currently REFUSES to move funds (Shield SDK + PXE + delegated personhood land at the v5 rollout). You PLAN and hand off; you execute nothing until then.\n\nDATA HONESTY: the scan uses full tx history if an Etherscan key is present, otherwise a keyless recent window. Always say which mode you used. NEVER give a false all-clear in keyless mode — say \"no links in the recent window; run with full history to be sure.\" Prioritize the links most likely to deanonymize the owner. All data is keyless (ENS reverse, public RPC, GoPlus/OFAC feeds; optional Etherscan full history) — no external service required.", |
Member
Author
There was a problem hiding this comment.
im not sure read only is accurate here, please audit
Member
Author
There was a problem hiding this comment.
all briefs should not be here but in aex repo docs, maybe its ok to stay here as long as we dont open source them
Member
Author
There was a problem hiding this comment.
all briefs should not be here but in aex repo docs, maybe its ok to stay here as long as we dont open source them
Member
Author
There was a problem hiding this comment.
all briefs should not be here but in aex repo docs, maybe its ok to stay here as long as we dont open source them
hebbianloop
pushed a commit
that referenced
this pull request
Jun 25, 2026
…drop 'Off-chain' + mark briefs internal (PR #53 review) Signed-off-by: Shady El Damaty <shady@holonym.id>
Member
Author
|
Addressed in 6f49ad5:
|
…y (PR #53) Rebuilt onto current main (agent-only diff). Addresses #53 review: PRIVACY_CHAIN multichain; analysis-only wording; runtimes=[nous,claude,openclaw] (recipe-based compatibility per Shady); briefs marked internal + export-ignore; sanitized. Signed-off-by: Shady El Damaty <shady@holonym.id>
hebbianloop
force-pushed
the
shady/privacy-guard
branch
from
6f49ad5 to
a6a818d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds Privacy Guard from a stub into the Sybil-clustering engine inverted to protect the user — it finds what links the wallets they want kept separate, and what publicly deanonymizes each, with the concrete fix for every link.
Stacked PR on
shady/security-guard(batch-1 stack). Clean diff: privacy-guard only. Re-target tomainafter the stack lands.What it does (read-only)
direct_transfer(definitive) ·shared_funder(strong) ·shared_counterparties(medium; common infra like USDC/routers excluded) — each with the how-to-break step.Data honesty
Full tx history when
ETHERSCAN_API_KEYis set (infra #11) — the reliable mode for a real audit; otherwise a keyless recent window, honestly labeled. Never a false all-clear in keyless mode. (Verified: ENS reverse = vitalik.eth, footprint, and the pairwise set-logic; the keyless topic-only getLogs is rate-limited on very active wallets, which is exactly why it defers to Etherscan for full history.)On-brand: the same clustering that protects $512M+ of airdrops from Sybils, pointed the other way. Fifth Batch-1 agent. Relates to testing protocol #1464.
🤖 Generated with Claude Code