The New “Link Your Wallets” Standard Sounds Convenient — Until It Links Your Life Too

A draft Ethereum standard called ERC-8092 (“Associated Accounts”) is gaining attention for a simple promise: let two blockchain accounts prove they’re connected — and later unlink them — using signatures rather than a central middleman. Much how like how Delegate works today, but implementing it at the protocol level.

In plain English: it’s like creating a verifiable “these two accounts belong together” badge that apps can read, whether the record is stored onchain or offchain.

That sounds harmless… until you ask the uncomfortable question:

What happens when “linking accounts” becomes “linking identity”?

ERC-8092 is designed for real use cases: delegation (letting one account act for another), inheritance/recovery, and reputation aggregation across multiple wallets and chains.

And it’s built to work cleanly across chains using interoperable address formats (ERC-7930).

But the security risks aren’t sci-fi. They’re the same kinds of real-world mistakes people already make — just supercharged by crypto’s permanence.

The biggest risks (non-technical, real-world version)

1) The “public relationship status” problem

Linking accounts is like putting your personal and business phone numbers on the same public profile.

Even if you meant to make life easier, you may also make it easier for others to:

• connect your wallets across chains,

• map your activity,

• target you with tailored scams.

If the association is recorded onchain, it can be effectively permanent breadcrumbs. ERC-8092 explicitly supports public proof and optional onchain storage.

2) “Just sign here” — signature phishing on steroids

Most people don’t read what they sign. Scammers know this.

ERC-8092 relies on signed records to establish the link.

That creates a new category of scam prompt:

“Sign this to verify your wallet / claim your airdrop / continue.”

Except now the signature can be weaponised as a credible-looking association that other apps might trust.

Analogy: you think you’re signing for a parcel delivery — but it’s actually a form that makes you someone’s legal guarantor.

3) The “one key opens many doors” cascade

ERC-8092 is often discussed alongside delegation and sub-account relationships.

If apps start treating “associated” as “trusted”, then compromising one linked account can become a domino effect:

• a weaker hot wallet becomes the bridge to a stronger vault wallet,

• a compromised device becomes the bridge to a passkey account,

• a hacked app session becomes the bridge to your “main identity”.

Analogy: you didn’t just lose a key — you lost the keyring, and now the labels tell thieves which doors matter most.

4) Revocation isn’t magic if apps don’t check it properly

ERC-8092 includes a lifecycle (validity timestamps and revocation).

But in practice, risk often comes from the boring stuff:

• apps cache old data,

• indexers lag,

• a UI shows “unlinked” while some service still accepts the old link.

5) “Offchain convenience” can become “offchain confusion”

The draft allows associations to be stored offchain as well as onchain.

Offchain can be great for cost and privacy — but it can also mean:

• a service “loses” your revocation,

• different providers show different truths,

• availability problems at the worst moment.

6) Cross-chain mix-ups: the wrong address on the wrong chain

ERC-8092 leans on ERC-7930 to avoid ambiguity across chains.

Still, real-world UX can fail: people paste addresses, wallets display shortened strings, and chain context gets missed.

The uncomfortable bottom line

ERC-8092 itself is trying to standardise something people already do informally: “this wallet is also me.”

The danger is how quickly the ecosystem could start treating associations as authority, and how easily users could be tricked into creating links they didn’t truly intend.

Overall, this is essentially a more standardised way to do what some third-party services already offer today — but with a common protocol that could make integrations cleaner and more consistent.

That said, it can feel like scope creep towards making more people publicly identifiable onchain, which privacy advocates strongly oppose. And with popular dapps already nudging users to link accounts (for convenience and “better UX”), the direction of travel is clear.

Ultimately, if onchain identity became the default for everyone, it could actually reduce today’s “two-tier privacy” dynamic — where some people stay private while others are effectively exposed.

In other words, eradicating the current “privacy for me, but not for you” system would reduce corruption that exploits loopholes, increase transparency, and ultimately create a more level playing field.