Why
Wallet addresses are the worst of both identity worlds: too sticky to be anonymous, too loose to be an account. The person is many wallets (hot, cold, work, mobile, the one from 2021); sometimes the wallet is many people (a team multisig, a shared ops key). Every product question — whose purchase history, whose loyalty points, who can the support desk talk to — lands on a mapping the chain does not provide.
Sign-In-With-Ethereum narrows this but does not close it: a valid SIWE session proves the presenter controls the key now — it says nothing about whether that presenter is the same human as yesterday, or the only one. So the account model is an application design decision with real security edges: wallet linking is an authorization graph, and the unlink operation is where account-takeover hides. Getting it wrong is how a stolen hot wallet becomes a stolen whole account.
How it works
An account service, two linked wallets, and the three edge cases that define the model.
PoC
A small app (SIWE via viem, SQLite accounts): create an account with wallet A, link wallet B by signing a challenge from an already-authenticated session. Then implement and test the edges: (1) unlink policy — require the action from the remaining wallet, and add a time-locked grace period so a thief who links their wallet cannot immediately evict yours; (2) history — purchases stay with the account, not the wallet, and show what unlink means for them; (3) shared wallet — wallet B links to a second account and the code must choose: reject, allow-many, or transfer-with-consent. Each choice is a policy table row with a test.
What it proves
Account linking looks like a convenience feature and is actually an authorization system: every link is a granted capability, every unlink a revocation, and the timing rules between them are the account-takeover surface. The chain gives you a permissionless key graph; the product must decide, explicitly, what a person is.
Where it lands in Jayverse
- Wallet: model wallet-linking as an authorization graph. Require the remaining wallet's signature to unlink another, add a time-locked grace period, and keep purchase/settlement history with the account rather than the wallet.
- Rabbit: apply the same three policy rows to session keys. A valid ERC-4337/7702 session proves control of a key, not identity, so Rabbit's account and support model needs the same unlink-authority, history-ownership and shared-wallet tests as any linked-wallet account.
- Personas: decide the shared-wallet policy before the market ships. Reject, allow-many, or transfer-with-consent for a persona NFT tied to a wallet a team or multiple people control — pick one and test it, not after the first support ticket.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| the worst of both worlds | 양쪽의 단점만 모은 최악의 조합 · "the worst of both identity worlds" |
| sticky / loose | 딱 붙어 안 떨어지는 / 헐겁게 걸쳐진 · "too sticky to be anonymous, too loose to be an account" |
| land on | (문제가 결국) ~로 귀결되다 · "lands on a mapping the chain does not provide" |
| narrow ... but not close | 범위는 좁히지만 완전히 없애지는 못하다 · "narrows this but does not close it" |
| authorization graph | 누가 무엇을 할 수 있는지 보여주는 권한 관계도 · "wallet linking is an authorization graph" |
| account-takeover | 계정 탈취 · "the unlink operation is where account-takeover hides" |
| evict | (강제로) 쫓아내다, 내보내다 · "cannot immediately evict yours" |
| grace period | 유예 기간 · "add a time-locked grace period" |
| granted capability | 부여된 권한 · "every link is a granted capability" |
| SIWE | 이더리움으로 로그인(Sign-In With Ethereum) · 서명으로 키 통제권만 증명하는 인증 표준, 사람의 신원까지 증명하진 않음. "proves control of a key, not identity" |
| SQLite | SQLite · 별도 서버 없이 파일 하나로 동작하는 경량 임베디드 데이터베이스, 이 PoC의 계정 저장소로 쓰임. "SIWE via viem, SQLite accounts" |