NEXUS Smart Wallet V2

A self-custody smart wallet for Base: passkeys, ERC-4337 account abstraction, scoped AI-agent session keys, and gasless onboarding.

Garcia Holdings LLC · Elk Plain, WA · May 2026 (revised September 2026) Identity tag: $leonardgg100 · Target chain: Base (chain ID 8453)

Abstract

NEXUS Smart Wallet V2 is a specification and prototype for an ERC-4337 smart wallet on Base. It replaces the seed phrase with WebAuthn passkeys (P-256 signatures), gives AI agents scoped session keys instead of root-key custody, and uses a paymaster so users can transact without holding ETH. Wallet addresses are counterfactual: a $leonardgg100 identity tag resolves to a deterministic CREATE2 address on Base, so users can receive funds before their wallet contract is ever deployed.

This paper describes what the design specifies, what has been prototyped, and what is still roadmap. It does not describe a bank, a charter, or any institutional partnership. It describes software.

1. The problem

Three failures in the current tooling motivate this design:

1. Seed phrases are a single point of failure. The average user cannot secure a 256-bit secret for decades. Loss of the phrase means loss of the funds, permanently. This is protocol failure, not user error.

2. The first-transaction problem. A user receives USDC on Base but holds 0 ETH. They cannot send anything until they on-ramp ETH. Gas as a prerequisite breaks every new-user funnel.

3. AI agents cannot act safely. To let an AI agent pay on a user's behalf today, the user must hand it a root key or seed phrase. The agent can then do anything, including draining the account. There is no standard mechanism for scoped delegation — a key that can spend up to $500 on Uniswap for one hour and nothing else.

NEXUS addresses all three with existing, deployed standards: ERC-4337 account abstraction, WebAuthn passkeys, and ERC-7579 modular validation.

2. Architecture

2.1 ERC-4337 account abstraction

The wallet is a smart contract account following the ERC-4337 standard (EntryPoint v0.7). Instead of signing raw transactions with a private key, the user (or their agent) submits a UserOperation: a structured object containing the sender, nonce, call data, and signature. A decentralized network of bundlers batches UserOperations and submits them to the EntryPoint contract, which verifies each operation and executes it.

• EntryPoint: v0.7, deployed at 0x0000000071727De22E5E9d8BAf0edAc6f37da032 (the canonical v0.7 deployment).
• Account implementation: UUPS-upgradeable contract, deployed per-user via a factory. Validation logic is modular (ERC-7579), so passkey validation, session-key validation, and recovery can be installed as modules rather than baked into the account.
• Batching: EIP-5792 wallet_sendCalls lets approve + swap + stake execute in a single UserOperation. EIP-7702 (Type 0x04) EOA delegation is an optional migration path for existing EOAs; it is not required.

2.2 Passkeys instead of seed phrases

The root credential is a WebAuthn passkey. The authenticator (phone secure enclave, hardware key) holds a P-256 (secp256r1) keypair; the wallet contract verifies P-256 signatures on-chain.

• RIP-7212 on Base provides a precompiled contract for secp256r1 signature verification, making passkey validation cheap enough for routine use. This is the technical reason Base is the target chain.
• No seed phrase is generated, displayed, or stored. There is nothing to write down and nothing to lose in the traditional sense.
• Quantum resistance: not claimed. P-256 is not quantum-resistant. Post-quantum signature schemes are research-only and are not part of this design. Any document that previously described these passkeys as "quantum-safe" was wrong; this paper corrects that.

2.3 Scoped session keys for AI agents

The core delegation primitive. A session key is a short-lived, tightly scoped signing key granted to an AI agent (the reference agent in this project is called Nave). The session key is validated by an ERC-7579 module on the account, and every constraint is enforced on-chain — not by trusting the agent.

Concrete example policy (the reference policy used in the prototype):

The root key never leaves the device's secure enclave (StrongBox / Secure Enclave). The session key lives in memory on the agent's host, is revocable at any time by the root key, and cannot exceed its scope even if the agent is compromised. Natural-language instructions from the user are translated into a signed UserOperation that must satisfy every session-key constraint or the EntryPoint rejects it.

2.4 Paymaster: gas is a UX bug

Users should not need ETH to send USDC. Two paymaster modes are specified:

• Sponsored mode: a paymaster sponsors the user's operations so no ETH is needed (roadmap — sponsor entity and funding not finalized).
• ERC-20 mode: the user pays gas in USDC; the paymaster swaps USDC → ETH via an oracle price and pays the EntryPoint.

The bundler layer (candidates: Pimlico, Stackup, Alchemy) is roadmap — no bundler integration exists in the current prototype.

2.5 Recovery

Losing a device must not mean losing the wallet. Three recovery mechanisms are specified:

• Social recovery: a 3-of-5 guardian set can rotate the account owner to a new passkey. The address persists; the keys do not. (Roadmap — guardian UX and the recovery module are not implemented.)
• Passkey/biometric recovery: platform authenticators support cloud-synced passkeys as a soft recovery path.
• Institutional recovery: a custodial attestor as an additional recovery option. (Roadmap — no attestor exists.)

The recovery module pattern follows established ERC-4337 recovery-module designs. Until guardians are implemented, the prototype has no recovery — this is stated plainly because it is the single largest risk in the current state.

3. Identity: $leonardgg100

One human-readable tag resolves to the user's wallet deterministically on every supported rail. The mechanism:

• The smart wallet address is counterfactual: address = hash(CREATE2, factory, salt = keccak256("$leonardgg100"), initCode). Anyone can compute the address without the contract being deployed.
• A registry contract maps the tag to its counterfactual address (ENS-like resolution; registry is roadmap).
• The user can receive funds to the address before the wallet exists. The first UserOperation triggers deployment and execution atomically through the factory.

This gives a Venmo-like handle ($leonardgg100) with self-custody underneath — no username server holds funds.

4. Bridging and payments

4.1 Multi-curve identity

EVM chains use secp256k1 (and P-256 for passkeys); Solana uses Ed25519. No single key works for both. The design bridges curves with a program-derived-address (PDA) scheme: the $leonardgg100 tag resolves to a deterministic address on each rail. The Solana side is not built. EVM bridging between Base and other EVM chains follows standard bridge patterns; no proprietary bridge is claimed.

4.2 Android IP Wire and P2P Tap

For in-person payments, the phone is the backend — no cloud intermediary after the handshake:

• Discovery: mDNS broadcast (garcia-holdings.local) plus WebRTC signaling for session setup.
• Proximity proof: an RTCDataChannel (DTLS 1.3) round-trip-time gate — RTT under 50ms counts as a "tap." This is not NFC or Bluetooth; it works cross-platform (iOS Safari ↔ Android Chrome PWA). NFC NDEF and Titan M2 tokenization are specified as fallback paths on Android.
• Settlement: the QR code carries only payment intent, never a secret. Execution goes through the user's existing consumer apps (Cash App $leonardgg100, PayPal.me, Google Pay PaymentRequest API) or, once the wallet is live, a direct USDC UserOperation. No server holds funds at any point.

IP Wire is roadmap — the WebRTC P2P transport has been prototyped separately, but it is not integrated with the wallet.

5. Hardware companion: the GUA vault

The GUA hardware vault is a separate, complementary project: a physical signing device for users who want their keys off their phone.

• Hardware: Raspberry Pi Compute Module 4 on a Waveshare IO carrier, ATECC608B secure element plus OPTIGA TPM (SLB9670), custom aluminum enclosure (120×120×80mm).
• Key custody: the private key is generated inside the ATECC608B and never leaves the chip. Signing happens via ECDH challenge-response; the host never sees key material.
• Tamper response: a PCB-edge tamper mesh wired to the TPM's tamper pin — a physical breach wipes the NVMe key slot. TPM PCRs measure the bootloader and kernel; an unsealed boot refuses to sign.
• Air-gap default: hardware kill switches physically disconnect the WiFi antenna trace and Ethernet magnetics. Default boot loads no WiFi driver; the firewall drops everything. The device only touches the network to broadcast a signed transaction, and only when the operator enables it.
• Purpose: offline proof-of-creation for artists (hash of the work anchored to Base) and cold signing for the NEXUS wallet. Open-hardware spec, CC BY-SA 4.0, no warranty.

The GUA vault is a hardware design with a build procedure. It is not a manufactured product.

6. Security analysis

What the cryptography provides, stated without exaggeration:

• Passkey signatures (P-256): ~128 bits of classical security. Resistant to all known classical attacks. Not resistant to a cryptographically relevant quantum computer. Migration to post-quantum signatures would require an account upgrade (the UUPS + modular validation design makes this possible; no PQ module exists).
• Session-key scoping: enforced by the account's validation module and the EntryPoint, not by the agent's goodwill. The residual risk is oracle risk (Chainlink feed manipulation or staleness) and module bugs — both are in the audit scope before mainnet.
• Counterfactual addresses: deterministic and griefable in theory (anyone can deploy to the address first with different init code — the registry must commit to the canonical init code hash). Front-running the deployment does not steal funds already sent to the correct counterfactual address.
• The largest current risk is the absence of recovery. Until guardians are implemented, losing all authenticators means losing the account. This paper does not minimize that.
• No part of the current prototype has been audited. The local-chain tests cover the token contract's encumbrance logic, not the wallet account, factory, or modules. A professional audit is a prerequisite for mainnet.

7. Real vs. roadmap

The UI prototype builds no UserOperations, integrates no bundler, and contains placeholder factory/implementation addresses. It is a design model, not a working wallet, and this paper does not present it as one.

8. Roadmap

• Q2 2026 — Smart wallet account + factory design; session-key policy model; UI prototype. (Design phase — complete.)
• Q3 2026 — Passkey registration flow; $leonardgg100 counterfactual address design; Base Sepolia testnet target.
• Q4 2026 — Social recovery design (3-of-5 guardians); paymaster research; bundler integration.
• Q1 2027 — Wallet production release target; Android IP Wire P2P integration; tap-to-pay prototype.

Dates are targets, not commitments. Anything listed here that is not built is labeled roadmap wherever it appears.

9. Open items

1. Bundler selection and integration — required before any testnet UserOperation.
2. Recovery module implementation and guardian UX — the highest-priority safety work.
3. Professional security audit of the account, factory, validation modules, and paymaster — prerequisite for mainnet.
4. Registry design for $leonardgg100 resolution with init-code-hash commitments.
5. Paymaster sponsor — funding and policy for gasless onboarding unresolved.
6. Solana bridge design — the Ed25519 side is unstarted.

10. Language standard

This paper describes only technology that exists or is explicitly specified as a design. The following categories of language are not used: banking or charter claims (no NCUA, CDFI, or credit-union charter exists or is presented as operating); UCC filing language; sovereign, nation-like, or governmental-authority framing; institutional partnership claims (no bank or payment network is presented as a partner or live integration); property deeds or titles presented as executed instruments; cooperative-as-existing-entity framing. Where the project touches regulated domains in the future, the work ships as an explicit roadmap item with one question answered first: what technology exists today, and what is only planned?

11. What this paper does not claim

• It does not claim NEXUS is a bank, a credit union, or a chartered financial institution of any kind. It is wallet software.
• It does not claim any partnership, integration, or endorsement by any bank, payment network, or institution. References to consumer payment apps describe user-operated rails, not partnerships.
• It does not claim the passkeys are quantum-resistant. They are not.
• It does not claim the UI prototype is a working wallet. It builds no UserOperations and has no on-chain presence.
• It does not claim any funds are held, managed, or insured by Garcia Holdings LLC. The design is self-custody: the user holds their own keys.
• It does not claim the roadmap dates as commitments, the audit as performed, or the Solana bridge as built.
• It is not legal, financial, or tax advice.

Document: NEXUS Smart Wallet V2 whitepaper · Garcia Holdings LLC · September 2026 revision. Supersedes the May 2026 draft. Technology-only revision: all institutional and sovereign language removed; quantum-safety claims corrected; roadmap items labeled as roadmap.