Context
While exploring the auth implementation (see #63), a third option emerged that's structurally different from the dexs-backend port: design the broker around pluggable layers with no hard Heima dependency in v0.
docs/spec/architecture.md §11 already documents audit anchoring as pluggable (Heima parachain, Ethereum, Solana, S3 Object Lock, SQLite, sealed log services all valid). This issue tracks extending the same principle to two more layers — user authentication and wallet provisioning — and exploring it on a separate branch.
The reframe
Three layers, all pluggable, v0 default in bold:
| Layer |
Plug-ins |
| User auth |
WalletSig (EIP-191 ecrecover), EmailLink (passwordless magic-link), OAuth2 (v1), LocalPasskey (v1.5), TeePasskey (v2 Heima) |
| Wallet provisioning |
ClientSideKeystore (CLI generates BIP-39, OS keychain), SmartContractAa (passkey-derived ERC-4337, v1.5), HeimaTee (v2), AwsNitro (v2 alt) |
| Audit anchoring |
Sqlite (already shipped), SolanaProgram (v1), EthereumL2 (v1.5), HeimaParachain (v2), S3ObjectLock (v2 alt) |
Each layer has a Rust trait; deployments pick plug-ins via TOML config; feature-gated dependencies in Cargo.toml mean v0 deployments don't link Solana/Heima/WebAuthn crates.
Full design: docs/research/option-c-pluggable-attestation-audit.md.
Why a separate branch
This is structurally incompatible with the Option A direction (#63) — it's not a refinement, it's a different architecture. Working on main or the Option A branch would force premature commitment to one approach.
Recommended branch: claude/agentkeys-pluggable-broker (or similar — name TBD).
Headline numbers vs Option A
|
Option A (port dexs-backend) |
Option C (this issue) |
| Heima patch for v0 |
~250 LOC |
None |
| Heima patch for v2 |
done |
~250–400 LOC (precise, after we know what we built) |
| v0 LOC |
~10,000 |
~1,500 |
| v0 calendar |
8–13 weeks |
4–5 weeks |
| Lock-in to Litentry |
High |
None for v0/v1 |
| China deployment |
Heima-bound |
One config row |
| Architectural ceiling |
Bound by dexs-backend assumptions |
Designed for AgentKeys |
Phases (per the plan)
v0 — fully self-contained, zero external deps (4–5 weeks)
v1 — chain-anchored audit + OAuth (3 weeks)
v1.5 — passkey + smart-contract AA wallet (4 weeks)
v2 — optional Heima integration (4 weeks AgentKeys side + Litentry's cycle)
Decision criteria
Pick Option C if any of:
- Heima coordination cost is the dominant schedule constraint
- China-jurisdiction deployment matters (avoid Heima dependency)
- We want maximum architectural future-flexibility for cross-chain audit / TEE-vendor swaps
- We want to ship a working broker in 4–5 weeks rather than 8–13
Stay with Option A (#63) if:
- Battle-tested code from day 1 is more important than design ceiling
- Heima alignment is a product requirement
- The team prefers "port working code" over "design new code"
Related
🤖 Generated with Claude Code
Context
While exploring the auth implementation (see #63), a third option emerged that's structurally different from the dexs-backend port: design the broker around pluggable layers with no hard Heima dependency in v0.
docs/spec/architecture.md §11 already documents audit anchoring as pluggable (Heima parachain, Ethereum, Solana, S3 Object Lock, SQLite, sealed log services all valid). This issue tracks extending the same principle to two more layers — user authentication and wallet provisioning — and exploring it on a separate branch.
The reframe
Three layers, all pluggable, v0 default in bold:
Each layer has a Rust trait; deployments pick plug-ins via TOML config; feature-gated dependencies in Cargo.toml mean v0 deployments don't link Solana/Heima/WebAuthn crates.
Full design: docs/research/option-c-pluggable-attestation-audit.md.
Why a separate branch
This is structurally incompatible with the Option A direction (#63) — it's not a refinement, it's a different architecture. Working on
mainor the Option A branch would force premature commitment to one approach.Recommended branch:
claude/agentkeys-pluggable-broker(or similar — name TBD).Headline numbers vs Option A
Phases (per the plan)
v0 — fully self-contained, zero external deps (4–5 weeks)
UserAuthMethod,WalletProvisioner,AuditAnchor(~400 LOC)user_id INTlegacy)agentkeys init wallet,agentkeys init emailv1 — chain-anchored audit + OAuth (3 weeks)
v1.5 — passkey + smart-contract AA wallet (4 weeks)
webauthn-rs; ~500 LOC)v2 — optional Heima integration (4 weeks AgentKeys side + Litentry's cycle)
Decision criteria
Pick Option C if any of:
Stay with Option A (#63) if:
Related
🤖 Generated with Claude Code