Salud Capital
■ CONFIDENTIAL — NOT FOR CVS HEALTH / AETNA / ANY EXTERNAL PARTNER
SaludID Plus — Premium Sovereign Identity Vault Spec  ·  April 2025

Internal Technical Specification · Premium Product Architecture · Tangem Ring · Multi-Partition Identity

SaludID Plus — The Sovereign Identity Ring

A premium, four-partition identity vault that isolates government & healthcare credentials, financial identity, developer secrets, and recovery keys in cryptographically separate compartments — all unlocked by a single Tangem Ring NFC tap. CVS Health and all healthcare partners see only Partition 0 via scoped zero-knowledge proofs. Partitions 1–3 are cryptographically invisible to any external party. Now with Unstoppable Domains anchoring each partition's user-facing identity: P0 uses saludcap.x as the healthcare identity string at MinuteClinic, P1 uses saludcap.bitcoin for financial addressing, P2 anchors “Login with Unstoppable” OAuth, and P3 stores guardian UD domains for recovery coordination.

P0 — Healthcare / Gov P1 — Financial Identity P2 — Credential Vault P3 — Recovery & Legacy ERC-7231 Multi-Identity BIP-32 HD Hardened Keys FIDO2 / WebAuthn Bridge CVS-INVISIBLE — ZK Scoped Access
Token standard
ERC-7231
Finalized multi-identity NFT standard
Key architecture
BIP-32 HD
Hardened derivation — partition isolation
Hardware
Tangem Ring
EAL6+ · wearable · same chip as card
Credential bridge
FIDO2
WebAuthn + CTAP2 over NFC — ring = security key
Partner visibility
P0 only
Healthcare partners see P0 ZK proof exclusively
Premium price
+$15/mo
Above base Salud Vault plan

01   Core Concept

One Ring. Four Cryptographic Compartments. One Tap Unlocks the Right One.

Standard SaludID stores a single healthcare credential set, partially visible to CVS Health via scoped access. SaludID Plus is an entirely different product: a sovereign identity vault with four cryptographically isolated partitions, each encrypted with a different child key derived from the Tangem ring's EAL6+ master hardware key via BIP-32 hardened derivation. No partition can reveal any information about any other partition. CVS Health and all healthcare partners see only Partition 0 — and cannot even detect the existence of Partitions 1, 2, or 3.

// The Cryptographic Foundation — BIP-32 Hardened Partition Isolation

Each partition derives its signing and encryption keys from the ring’s EAL6+ secure element using BIP-32 hardened derivation: m/44'/7231'/partition'. Hardened derivation means a compromise of any child key — even when paired with the parent’s extended public key — cannot reveal the parent key or any sibling partition key. This is the same mathematical property that lets HD wallets share public keys without exposing private keys. Each partition is a cryptographic island. CVS gets a scoped zero-knowledge presentation from Partition 0 only. They receive no signal that other partitions exist.

4
Cryptographically isolated partitions on one ring
ZK
Scoped proofs — prove healthcare eligibility without revealing any credential data
FIDO2
WebAuthn + CTAP2 over NFC — ring replaces every security key and password manager
0
Bytes stored on Salud, CVS, or any partner server — chip + IPFS only

02   Four-Partition Architecture

What Lives in Each Compartment — and Who Can See It

Partition 0  ·  m/44'/7231'/0'
Healthcare & Government
Scoped ZK access only
ID.me verified identityCMS-verified OIDC token
CLEAR biometric anchorMedicare.gov access
Medicare ID (MBI hash)Part A / B / D enrollment
Medicaid enrollmentState MCO assignment
Aetna member credentialsCVS Health plan ID
MinuteClinic access tokenCopay + insurance verify
CVS Rx benefit IDPart D formulary + Rx
HSA / FSA tokensSmart contract spend rights
Passport / State ID hashGovernment ID anchor
Partition 1  ·  m/44'/7231'/1'
Financial Identity
Private — chip only
Bank account OAuthPlaid access tokens
Brokerage credentialsSchwab, Fidelity, IBKR
Credit profile anchorFICO score hash
Crypto wallet xPubsMulti-chain HD addresses
USDC / stablecoin vaultCircle wallet credentials
SSN / EIN hashTax identity anchor
ACH routing tokensEncrypted bank ACH
Apple / Google PayPayment card tokens
Open Finance tokensFHIR financial data
Partition 2  ·  m/44'/7231'/2'
Credential Vault
Developer / Pro tier
FIDO2 passkeysRing IS the authenticator
Google Password ManagerWebAuthn backup key
Apple KeychainiCloud passkey anchor
Bitwarden / 1PasswordFIDO2 MFA security key
SSH private keysEd25519, deterministic
API keysAES-256-GCM encrypted
OAuth refresh tokensGitHub, AWS, GCP, Azure
GPG / code-signing certDerived from P2 key
Desktop credential agentmacOS / Windows / Linux
Partition 3  ·  m/44'/7231'/3'
Recovery & Legacy
Guardian key only
Emergency accessTime-locked guardian unlock
Estate planning docsWill hash + trust docs
Healthcare proxyHIPAA auth representative
Digital asset inheritanceTime-locked recovery xPub
Backup ring addressSecond ring hardware link
3-of-5 guardian shardsShamir Secret Sharing
Emergency contactsEncrypted contact list
Legal PoA hashPower of attorney anchor
Death trigger protocolChainlink automation
// Why Partition 3 (Recovery) Changes Everything for Seniors

The single most painful gap in digital credential management for seniors is the "death problem" — when a spouse dies, digital assets, credentials, and healthcare proxies are inaccessible. Partition 3 solves this with a time-locked guardian protocol: three trusted family members each hold a Shamir Secret Sharing shard. After a configurable absence period (e.g., 90 days of inactivity), the guardians collectively unlock Partition 3 to access estate documents, the healthcare proxy, and legacy credentials. The ring cannot die — the EAL6+ chip has a 25-year rated lifespan. The Chainlink Automation trigger fires only after guardian quorum + absence threshold are both met.

03   BIP-32 Hierarchical Key Derivation

The Cryptographic Foundation — How Partitions Stay Isolated

★ Unstoppable Domains Are Above the Cryptographic Boundary

UD domains are user-facing identity labels mapped to addresses. They sit entirely above the BIP-32 hardware layer. A UD domain does not derive from any partition key and cannot reveal any key material. Leaking saludcap.bitcoin (P1 label) reveals only a BTC address — it reveals zero information about P0, P2, or P3 keys. The BIP-32 hardened isolation guarantee is fully preserved.

BIP-32 hierarchical deterministic key derivation allows one master key (generated inside the Tangem ring’s EAL6+ secure element at first setup and never exported) to deterministically produce child keys for each partition. The critical property for SaludID Plus is hardened child key derivation — indicated by the apostrophe in the derivation path. A hardened child key cannot have its parent reconstructed even if both the child private key AND the parent’s extended public key are known. This mathematical guarantee means leaking a credential from Partition 2 (developer credentials) reveals nothing about Partition 0 (healthcare) or any other partition.

// BIP-32 Hardened Partition Key Derivation — inside Tangem EAL6+ chip only
// Master key generated at ring setup using hardware entropy — NEVER leaves chip
MasterKey = HMAC-SHA512("SaludIDPlus", ring_hardware_entropy)

// Hardened child keys (apostrophe = hardened = BIP-32 index + 2^31)
// A leaked child key + parent xPub CANNOT reconstruct any sibling or parent key
P0_key = CKDpriv(MasterKey, 44'/7231'/0')   // Healthcare
P1_key = CKDpriv(MasterKey, 44'/7231'/1')   // Financial
P2_key = CKDpriv(MasterKey, 44'/7231'/2')   // Credentials
P3_key = CKDpriv(MasterKey, 44'/7231'/3')   // Recovery

// Per-partition purpose sub-keys (also hardened)
P0_sign_key   = CKDpriv(P0_key, 0')   // Signs W3C Verifiable Presentations for CVS/CMS
P0_enc_key    = HKDF(P0_key,  "P0_ENC_v1")   // AES-256-GCM encrypts P0 data on chip + IPFS

P2_fido2_key  = CKDpriv(P2_key, 0')   // FIDO2/WebAuthn CTAP2 authenticator key
P2_ssh_key    = CKDpriv(P2_key, 1')   // Ed25519 SSH signing key (deterministic)
P2_gpg_key    = CKDpriv(P2_key, 2')   // GPG / code-signing certificate key
P2_api_key    = HKDF(P2_key,  "P2_API_v1")   // AES-256 encrypts stored API keys in IPFS vault

// ISOLATION GUARANTEE (mathematical, not policy):
// Know P1_key + MasterKey extended public key? Cannot derive P0, P2, P3, or MasterKey.
// CVS/Aetna receive: ZK proof signed by P0_sign_key only. Zero key material shared.
// Partitions 1/2/3 existence: cryptographically undetectable from P0 ZK proof.

Derivation Path Reference

PartitionDerivation PathVisible to Partners?Key UsageData Location
P0 Healthcarem/44'/7231'/0'ZK scoped onlySign W3C VP for CVS / CMS / ID.meRing chip + IPFS (encrypted)
P1 Financialm/44'/7231'/1'NeverDecrypt bank/brokerage tokens; crypto xPubsRing chip ONLY (no IPFS)
P2 Credentialsm/44'/7231'/2'NeverFIDO2 authenticator; SSH; GPG; API key decryptRing chip + IPFS (double-encrypted)
P3 Recoverym/44'/7231'/3'Guardian quorum onlyShamir anchor; estate unlock; healthcare proxyRing chip + 3-of-5 guardian shards
All key derivation occurs inside the EAL6+ chip. No key material transits to phone, app, or network. Chip is the trust root.

04   ERC-7231 On-Chain Token

SaludIDPlus.sol — Only Commitment Hashes On-Chain, Nothing Readable

The on-chain ERC-7231 token stores zero personal data. For each active partition, it records a commitment hash — proof that the partition data exists and is authentic (signed by the ring) without revealing any data. Healthcare partners can verify a valid P0 credential exists by checking the commitment against a ZK proof. They cannot determine whether P1, P2, or P3 partitions exist.

// SaludIDPlus.sol — ERC-7231 Premium Token — Polygon PoS
struct PartitionCommitment {
  bytes32 commitmentHash;  // keccak256(partition || ring_addr || data_hash || nonce)
  uint64  lastUpdated;     // Unix timestamp of last partition data update
  uint8   schemaVersion;   // Credential schema version (forward compatibility)
  bool    active;          // Is this partition provisioned?
}

struct IdentityRecord {
  PartitionCommitment p0_healthcare;  // P0: only partition with authorized access

  // P1/P2/P3: existence not publicly confirmable — double-blinded
  bytes32 p1_blinded;  // keccak256(P1_commitment || ring_salt) — unlinkable to content
  bytes32 p2_blinded;  // keccak256(P2_commitment || ring_salt)
  bytes32 p3_blinded;  // keccak256(P3_commitment || ring_salt)

  address ringAddress;      // Tangem ring's ERC-4337 smart account address
  bytes32 ringFingerprint;  // keccak256(ring_public_key) — verifies hardware binding
  bool    premiumTier;      // True = all 4 partitions active
}

// P0 healthcare ZK verification — the ONLY function external partners can call
function verifyHealthcareCredential(
  uint256 tokenId,
  bytes   calldata zkProof,       // ZK: "ring holds valid P0 credential matching commitment"
  bytes32          requestedClaim // Which claim (e.g. "medicare_part_b_enrolled")
) external view returns (bool valid, uint64 proofExpiry) {
  PartitionCommitment storage p0 = identities[tokenId].p0_healthcare;
  require(p0.active, "P0 not provisioned");
  valid = IZKVerifier(zkVerifier).verifyPartitionClaim(
    p0.commitmentHash, requestedClaim, zkProof
  );
  proofExpiry = uint64(block.timestamp) + 900; // 15-minute proof window
}

// P1/P2/P3: NO public function exists to confirm their state or content
// Private partition access: ring holder only, via NFC signing session

// ERC-5192 lock — SaludID Plus is NEVER transferable
function locked(uint256) external pure returns (bool) { return true; }

// Guardian recovery — P3 unlock after absence period + 3-of-5 shard quorum
function initiateGuardianRecovery(uint256 tokenId, bytes32[3] calldata shards) external {
  require(block.timestamp > identities[tokenId].lastActivity + ABSENCE_THRESHOLD);
  // Validate Shamir reconstruction, emit RecoveryInitiated, off-chain P3 decrypt begins
}

05   FIDO2 / WebAuthn Bridge — The Ring as Universal Security Key

Partition 2 Makes the Ring Replace Every Password Manager and Security Key

The Tangem ring’s EAL6+ chip speaks CTAP2 (Client to Authenticator Protocol v2) over NFC — the same protocol that YubiKey and other FIDO2 security keys use. This means the ring can natively register as a FIDO2 roaming authenticator at any WebAuthn-enabled service. The P2 partition key signs authentication challenges. Users simply tap their ring near an NFC reader or their phone.

// What FIDO2 + NFC Means in Practice

When the user taps their SaludID Plus ring near an iPhone or desktop NFC reader, the ring responds to CTAP2 challenges over NFC. Every service that supports WebAuthn (Google, Apple, Microsoft, GitHub, AWS console, Cloudflare, and 800+ others) sees a FIDO2 security key. The ring’s P2 signing key signs the authentication challenge inside the EAL6+ chip. The user just taps. No password, no 2FA app, no authenticator code — one ring tap.

Credential Manager Compatibility

Platform / Service P0 Healthcare P1 Financial P2 Credentials Integration Method
Google Password ManagerInvisibleInvisibleYes — passkey anchorWebAuthn API: ring registered as Google account FIDO2 security key / passkey backup
Apple Keychain / iCloudInvisibleInvisibleYes — passkey anchoriOS WebAuthn API: ring tap authenticates to iCloud Keychain. Same NFC position as Apple Pay.
1PasswordInvisibleInvisibleYes — FIDO2 MFA1Password FIDO2 key registration: ring tap = vault unlock. Removes master password dependency.
BitwardenInvisibleInvisibleYes — WebAuthn 2FABitwarden Premium WebAuthn: ring registered as security key. NFC tap = Bitwarden auth.
Microsoft Entra IDInvisibleInvisibleYes — AAL3NIST AAL3 phishing-resistant auth. Ring registered in Entra FIDO2 policy. Enterprise SSO via ring tap.
GitHub / GitLabInvisibleInvisibleYes — passkey + SSHFIDO2 passkey for web login. SSH key: Ed25519 derived from m/44'/7231'/2'/1' — deterministic, registerable at GitHub.
AWS / GCP / Azure CLIInvisibleInvisibleYes — agent bridgeDesktop credential agent: ring tap → decrypt session credentials from P2 vault → inject to CLI for 15 min → auto-expire.
CVS Health / AetnaZK scoped onlyInvisibleInvisibleCVS sees only ZK proof from P0. P1 and P2 are cryptographically undetectable from P0 access.
Medicare.gov (ID.me)P0 ZK + OAuthInvisibleInvisibleP0 stores ID.me OIDC token + CMS-verified MBI hash. Ring tap authenticates to Medicare.gov.
Bank / Brokerage (Plaid)InvisibleP1 OAuth tokenInvisibleP1 stores Plaid OAuth refresh tokens encrypted with P1 key. Ring tap decrypts for account access.

Desktop Credential Agent — API Keys Without Clipboard or Disk Exposure

For developers, the most transformative Partition 2 feature is the desktop credential agent: a lightweight daemon (macOS, Windows, Linux) that intercepts credential access patterns and injects API keys from the ring’s encrypted vault on demand. AWS access keys never sit in ~/.aws/credentials. GitHub tokens never live in .env files. Nothing persists on disk after the session ends.

// Desktop Credential Agent — ring tap injects credential, auto-expires after 15 min
def credential_request_flow(service_name, cred_type):
    # 1. Agent intercepts service request (git push, aws s3 ls, docker push)
    challenge = generate_challenge(service_name, cred_type)

    # 2. Send NFC challenge to ring via phone BLE bridge
    #    User sees notification: "Tap ring to approve AWS credentials"
    ring_sig = tangem_sdk.sign_nfc(challenge, partition=2,
                                    path="m/44'/7231'/2'/0'")

    # 3. Derive AES-256-GCM decryption key from ring signature + service context
    dk = HKDF(ring_sig.signature, label="P2_API_" + service_name)

    # 4. Fetch + decrypt credential from IPFS encrypted vault
    enc_cred = ipfs.get(P2_vault_manifest[service_name])
    credential = AES256GCM.decrypt(enc_cred, dk)

    # 5. Inject into OS session for exactly 15 minutes, then wipe
    inject_to_os_keychain(credential, ttl_seconds=900)

    # Credential NEVER saved to disk. NEVER in shell history. NEVER in clipboard.
    # If ring is removed from proximity, session immediately revoked.
// The Developer Value Proposition

The average developer maintains AWS access keys in 3+ places: terminal history, .env files, CI/CD secrets, clipboard. The average executive’s financial credentials live in a password manager behind a master password that can be phished. SaludID Plus replaces the entire credential surface with a ring tap. One touch. 15-minute session. Nothing persists on disk. This is YubiKey + 1Password + AWS Secrets Manager + SSH agent — in a ring — at $15/month above the Salud Vault base plan.

06   Scoped Access Architecture — CVS Cannot See Partitions 1, 2, or 3

What Each Partner Receives — and Is Cryptographically Blocked From

Every external access request produces a scoped W3C Verifiable Presentation (VP) revealing only the fields necessary for the specific request, signed by only the relevant partition key — inside the ring’s EAL6+ chip. The signing key never leaves hardware. CVS Health can verify Medicare enrollment without ever receiving a signal that the user holds financial credentials, developer credentials, or a recovery vault.

What CVS Health Receives from P0

  • ZK proof: "Medicare Part B enrolled = true" — binary, no underlying data
  • Scoped VP: Aetna copay amount for the requested service type
  • Scoped VP: CVS Rx benefit plan ID (read-only, for pharmacy lookup)
  • Proof expiry: 15-minute validity window
  • Ring fingerprint hash: verifies the physical hardware is present

CVS receives zero information about: MBI value, Medicaid status, financial accounts, developer credentials, or recovery configuration. They cannot determine whether P1/P2/P3 exist.

What CVS Health CANNOT Access

  • P1 existence: double-blinded hash on-chain — even the hash is unlinkable to content
  • P2 existence: same double-blinding, no public function confirms or denies
  • P3 existence: same double-blinding, guardian-only access after absence + quorum
  • Any P0 data beyond the scoped claim requested (e.g., cannot read SSN hash from P1 via P0 proof)
  • Ring master key: never exported, derived keys are partition-isolated by hardened BIP-32

The on-chain contract exposes only verifyHealthcareCredential() to external callers. All P1/P2/P3 functions are access-controlled to the ring address exclusively.

// ZK Proof Protocol for P0 Healthcare Verification

Challenge: CVS MinuteClinic tablet sends: {service_type, timestamp, clinic_id}. Ring signing (inside EAL6+ chip): Generates Groth16 ZK proof using P0 signing key that proves "this ring holds a valid Medicare enrollment credential matching the on-chain P0 commitment hash." Inputs (private): P0 raw credential data, P0 signing key, nonce. Inputs (public): P0 commitment hash (from chain), requested claim ID, proof expiry timestamp. Output: valid bool + copay amount for service type. CVS verifies proof on-chain against SaludIDPlus.sol. Total flow: ~2–3 seconds from tap to confirmed. MBI, full credentials, and all other partitions: never transmitted, never visible.

07   Build Plan — Claude Chat vs Claude Code Desktop

What to Build Where and in What Sequence

Task Tool Priority Deliverable Effort
Phase 1 — Smart Contract + Key Architecture (Weeks 1–10)
SaludIDPlus.sol — ERC-7231 4-partition token
PartitionCommitment struct, P0 ZK verify, P1/P2/P3 blinded hashes, guardian recovery, ERC-5192 lock
Claude Code Critical Hardhat, ERC-7231 base, full contract, 95%+ test coverage, Polygon Amoy deploy — completely separate from SaludID.sol 8–12 hrs
BIP-32 hardened partition derivation in Tangem SDK
Custom path m/44'/7231'/n' inside TangemSdk.startSession() — keys never leave chip
Claude Code Critical Swift + Kotlin: SaludIDDerivationPath protocol, partition-scoped signing sessions, chip storage layout for 4-partition data, AES-256-GCM encryption per partition using HKDF-derived keys 10–16 hrs
ZK proof circuit spec — Groth16 P0 healthcare verifier
Circom circuit design: prove P0 claim without revealing credential data or partition key
Claude Chat Critical Circom spec: private inputs (P0 credential data, P0 key, nonce), public inputs (commitment hash, claim ID, expiry), output (valid + selective disclosure). ZK specialist required to implement + audit Groth16 circuit. 4–6 hrs + specialist
Partition data encryption + IPFS layer
AES-256-GCM, HKDF key derivation, IPFS for P0/P2 only (P1/P3 chip-only)
Claude Code Critical Python/TS: HKDF(partition_key, context) → AES-256-GCM, IPFS CID generation, schema versioning. P1 and P3 chip-only (no IPFS) — GDPR right-to-erasure compliance by design. 6–10 hrs
Phase 2 — FIDO2 WebAuthn Bridge (Weeks 6–14)
FIDO2 CTAP2 NFC ring authenticator (P2)
iOS NFC-native + Android BLE bridge for CTAP2 PIN-protected credentials
Claude Code Critical Swift: ASAuthorizationController + CTAP2 NFC session, P2 signing key for WebAuthn assertion. Kotlin: FIDO2 BLE bridge (CTAP2-over-BLE to NFC-to-Tangem). Test against WebAuthn.io + real services. 12–18 hrs
SSH key derivation + agent integration
Ed25519 from m/44'/7231'/2'/1' — ring-signed SSH challenges
Claude Code High Python ssh-agent plugin: ring-signed SSH challenge via Tangem SDK, deterministic pubkey display for GitHub/GitLab registration, key rotation via path index increment 4–8 hrs
Phase 3 — Desktop Credential Agent (Weeks 10–18)
Desktop credential agent daemon
macOS + Windows + Linux: API key injection, 15-min TTL, auto-wipe on session end
Claude Code High Python: system tray daemon, pyscard PCSC integration (Token2 NFC reader), P2 HKDF key derivation, AES-256-GCM decrypt from IPFS, OS keychain injection (Keychain / DPAPI / libsecret), 15-min TTL wipe 16–24 hrs
AWS / GCP / Azure / GitHub credential profiles
Cloud CLI hooks: ring tap → inject session credentials → auto-expire
Claude Code High aws credential_process hook, gcloud auth helper, az CLI credential provider, gh CLI token injection. Each: ring tap → P2 decrypt → 15-min session credential → auto-expire and wipe. 6–10 hrs
Phase 4 — Recovery Protocol + Guardian System (Weeks 14–20)
Shamir Secret Sharing — P3 guardian setup
3-of-5 shard distribution, time-lock, Chainlink automation trigger
Claude Code High Python secretsharing: shard generation, guardian wallet binding, ABSENCE_THRESHOLD config. Chainlink Automation: inactivity monitor + guardian quorum check. Guardian companion app: shard storage + recovery initiation. 8–14 hrs
Digital estate + PoA legal spec
What goes in P3, how death trigger works, estate attorney review
Claude Chat Medium Spec doc: which legal documents constitute P3 estate data, how Chainlink automation triggers P3 unlock (absence + guardian quorum), how digital assets transfer via P3 xPub reveal. Draft for estate attorney review before implementation. 3–5 hrs + counsel
Continuous — Separation & Legal (Throughout All Phases)
Contract separation — SaludIDPlus stays hidden from CVS
Separate contract address, separate admin keys, no cross-reference to SaludID.sol
Claude Chat Critical Architecture review: confirm zero linkage between SaludID.sol (CVS-visible) and SaludIDPlus.sol (internal). Separate Polygon deployment, separate Polygonscan verification, separate Safe multisig admin wallets. 2–3 hrs
P1 Financial — GDPR / CCPA erasure compliance
Chip-only design avoids right-to-erasure IPFS problem — legal confirmation
Claude Chat Critical Legal memo: P1 chip-only (no IPFS) means right-to-erasure is satisfied by destroying or factory-resetting the ring. P0/P2 IPFS data requires user consent flows. Draft for GDPR/CCPA counsel review. 2–4 hrs + counsel

08   Risk Register — Risks Unique to SaludID Plus

What Can Go Wrong That Doesn’t Apply to Standard SaludID

High · Cryptographic
Non-Hardened Derivation Compromise
If any partition accidentally uses non-hardened BIP-32 derivation, a leaked child private key + parent extended public key reconstructs the parent key, compromising all sibling partitions.
Mitigation: All partition paths use hardened indices exclusively (m/44'/7231'/0' through m/44'/7231'/3'). Enforce at SDK protocol level: reject any derivation request that does not use hardened path segments. Audit in Claude Code review session.
High · Legal
P1 Financial Data on IPFS — GDPR Erasure
IPFS is content-addressed and by design immutable. Storing any personal financial data (even encrypted) on IPFS creates a GDPR/CCPA right-to-erasure problem. Encrypted data that cannot be deleted still violates erasure requirements.
Mitigation: P1 Financial partition is chip-only — zero IPFS storage. Erasure = factory reset the ring. P0 and P2 use IPFS with explicit user consent + delete-key-to-make-unreadable approach pending legal review.
High · Platform
Android FIDO2 NFC PIN Limitation
Android does not support PIN-protected FIDO2 over NFC (only USB). This means P2 FIDO2 authentication for PIN-protected services requires either a USB NFC reader or the BLE bridge companion app on Android — breaking the "one tap" promise for 40%+ of users.
Mitigation: iOS-first launch for P2 FIDO2 (NFC-native, full support). Android: BLE bridge app (Tangem phone app proxies CTAP2 from browser to ring via BLE). Document limitation clearly. Monitor Google Play Services v24+ for NFC CTAP2 resolution.
Medium · UX
Ring Loss — P1/P3 Chip-Only Data
P1 (financial credentials) and P3 (recovery) are chip-only. A lost ring means lost access to these partitions until recovery is initiated. Unlike a card, a ring may be harder to notice when lost.
Mitigation: Strongly recommend backup card (same BIP-32 master, provisioned at setup) as safe-deposit box backup. P1 credentials are OAuth tokens that can be re-issued by financial institutions. P3 guardian Shamir shards enable estate recovery without the ring.
Medium · Privacy
ERC-7231 On-Chain Fingerprinting
Even double-blinded partition hashes could theoretically be correlated if the blinding salt is derived from a predictable value. The ring’s permanent Ethereum address creates a linkable identity anchor across all on-chain activity.
Mitigation: Use ERC-4337 stealth addresses for all on-chain interactions. Ring salt generated from hardware entropy at setup — not deterministic. Separate ERC-4337 smart accounts for financial (P1) and credential (P2) activity, each using different derived addresses.
Low · Technical
ZK Proof Generation Latency at MinuteClinic
Groth16 proof generation for P0 healthcare ZK circuit may take 3–10 seconds on mobile. This is too slow for point-of-care check-in, where the interaction window is 1–2 seconds.
Mitigation: Pre-generate P0 ZK proofs on a rolling 1-hour basis while the app is open. Cache on device (encrypted with P0 key). At MinuteClinic, serve cached proof — valid for 15 minutes per contract. Stale cache: server-side proof generation in 2–3 seconds as fallback.

09   The Three Starting Prompts

Open Claude Code Desktop and Claude Chat and Run These Now

// Claude Code Desktop — Session 1 (SaludIDPlus Contract + BIP-32, ~3 hrs)

"In a new /contracts/premium/ folder in the Salud Vault Hardhat monorepo, create SaludIDPlus.sol extending ERC-7231 with: (1) PartitionCommitment struct (commitmentHash bytes32, lastUpdated uint64, schemaVersion uint8, active bool). (2) IdentityRecord mapping token IDs to: p0_healthcare as PartitionCommitment, p1_blinded/p2_blinded/p3_blinded as bytes32 (double-blinded salted hashes), ringAddress, ringFingerprint bytes32, premiumTier bool. (3) verifyHealthcareCredential(tokenId, zkProof bytes, requestedClaim bytes32) external view returns (bool valid, uint64 proofExpiry) calling an IZKVerifier interface. (4) ERC-5192 locked() always returns true, transferFrom always reverts. (5) initiateGuardianRecovery(tokenId, bytes32[3] shards) checking block.timestamp against ABSENCE_THRESHOLD constant. (6) All P1/P2/P3 partition functions access-controlled to ringAddress only — no public function can confirm P1/P2/P3 existence. Also create SaludIDPlusDerivation.swift implementing BIP-32 hardened path m/44'/7231'/n' in Tangem SDK sessions, with per-partition signing isolation and HKDF sub-key derivation for AES-256-GCM encryption. Deploy to Polygon Amoy completely separately from SaludID.sol with a different Safe multisig admin."

// Claude Code Desktop — Session 2 (FIDO2 NFC + SSH Agent, ~4 hrs)

"Build P2 FIDO2 integration for the SaludVault iOS app (Swift). The Tangem ring must act as a FIDO2 roaming authenticator using CTAP2 over NFC via the Tangem SDK. Required: (1) Registration flow: WebAuthn navigator.credentials.create() challenge → Tangem NFC session with derivation path m/44'/7231'/2'/0' → CTAP2 authenticatorMakeCredential response → return attestation object to WebAuthn RP. (2) Authentication flow: navigator.credentials.get() → Tangem NFC → CTAP2 authenticatorGetAssertion → return assertion. (3) SSH key display: derive Ed25519 pubkey from m/44'/7231'/2'/1' and display as openssh-format for GitHub/GitLab registration. (4) Android BLE bridge: CTAP2-over-BLE service that proxies Chrome’s CTAP2 NFC requests to the Tangem SDK, working around Android’s NFC PIN limitation. Test all flows against WebAuthn.io and a local FIDO2 test server."

// Claude Chat — Session 3 (ZK Circuit Spec + GDPR Architecture)

"Design the Circom/Groth16 circuit specification for SaludID Plus Partition 0 healthcare ZK verification. Private inputs: P0 raw credential JSON (Medicare/Medicaid/Aetna fields), P0 partition signing key (derived m/44'/7231'/0'/0'), a random nonce. Public inputs: P0 commitmentHash (from SaludIDPlus.sol on Polygon), requested claim ID string hash (e.g. keccak256('medicare_part_b_enrolled')), claim value (true/false), proof expiry timestamp, issuer public key hash (ID.me / CMS). Output: valid bool + single selective disclosure of the requested claim value. Constraint: circuit proves the credential contains the claim without revealing the MBI, any other credential fields, the partition key, or any P1/P2/P3 partition data. Also: design the GDPR/CCPA data architecture justifying P1 Financial as chip-only (no IPFS) — explain why this satisfies right-to-erasure, how P0/P2 IPFS data uses delete-key approach, and what user consent flows are needed for P0 IPFS storage. Draft legal memo for external counsel."