[design] Unify DVT crypto layer (AAStarValidator) with SuperPaymaster economic layer — stake-gated, operator-bound registration

[jhfnetboy]

Context — two DVT contract systems that don't talk to each other

Today the DVT has two independent, disconnected on-chain authorization systems:

	AAStarValidator (YetAnotherAA-Validator) — crypto layer	DVTValidator + Registry + GTokenStaking (SuperPaymaster) — economic layer
Identity key	nodeId (bytes32) + BLS G1 pubkey	operator address (EOA) + ROLE_DVT + GToken stake
Stores	registeredKeys[nodeId]→pubkey, isRegistered[nodeId] — no operator, no stake	isValidator[address], GToken lock, role
Register	registerPublicKey(nodeId, pubkey) — no stake gate (deployed AAStarBLSAlgorithm is onlyOwner)	addValidator(address) — checks Registry.hasRole(ROLE_DVT) + locked stake ≥ minStake
Verify	verifyAggregateSignature(nodeIds, sig, msgPoint) — checks isRegistered only, no stake/liveness	_requireActiveValidator — real-time role+stake liveness on every consensus call
Job	who can co-sign + verify the aggregate BLS signature	who staked + slashing + liveness

The problem is not overlap/override — it's a break. The signing identity
(nodeId+pubkey in AAStarValidator) and the economic identity (address+stake in
SuperPaymaster) are never bound to each other. Consequences:

• A BLS pubkey can be registered in AAStarValidator with zero stake — the signing
  key has no skin in the game.
• An operator can stake in SuperPaymaster with no effect on who can actually co-sign.
• Slashing can't punish a misbehaving signing node: DVTValidator doesn't know which
  nodeId belongs to which operator address.
• The production signing/verification path (dvt nodes → registerPublicKey →
  verifyAggregateSignature) is not connected to the economic layer at all.

Business goal

1. Single stake source of truth — GToken staked under ROLE_DVT in the SuperPaymaster
   Registry/GTokenStaking is the only place stake is managed. Every other contract
   reads it, never re-implements it.
2. Bind signing ↔ stake — a nodeId/pubkey is tied to a staked operator, so
   co-signing rights require economic backing and a misbehaving signer can be slashed
   through its operator.
3. Permissionless self-registration — an operator can stake + register their own DVT
   node without owner approval, with an owner toggle so we can bootstrap in a
   permissioned (onlyOwner) mode first and flip to permissionless when ready.
4. Keep the hot verification path cheap — no per-signature cross-contract reads.

Technical plan (proposed — to be challenged/finalized)

Bind by operator address; defer stake to SuperPaymaster; keep pubkey local.

YetAnotherAA-Validator — AAStarValidator

• Add mapping(bytes32 => address) public nodeOperator; — the operator that owns a nodeId.
• registerPublicKey(bytes32 nodeId, bytes pubkey) called by the operator
  (msg.sender):
  • record nodeOperator[nodeId] = msg.sender.
  • stake gate (when enabled): require
    Registry.hasRole(ROLE_DVT, msg.sender) and
    GTokenStaking.roleLocks(msg.sender, ROLE_DVT).amount ≥ Registry.getRoleConfig(ROLE_DVT).minStake.
  • toggle: bool public requireStake (owner-settable). false → bootstrap
    (onlyOwner registers, as today). true → permissionless-but-staked. This is the
    ①stake-check + ②toggle asked for.
• Store the SuperPaymaster Registry address (owner-settable), read-only.
• (Optional, later) verifyAggregateSignature adds a real-time liveness read per
  participating operator — off by default to keep gas/coupling low; discuss.

SuperPaymaster — Registry / GTokenStaking / DVTValidator

• Confirm/keep the read interfaces the crypto layer needs: Registry.hasRole,
  Registry.getRoleConfig(ROLE_DVT).minStake, Registry.GTOKEN_STAKING(),
  GTokenStaking.roleLocks(user, roleId). (All appear to exist as of DVTValidator 0.6.0.)
• Slashing linkage: to slash a misbehaving signer, DVTValidator needs
  nodeId → operator. Options: (a) AAStarValidator emits NodeBound(nodeId, operator)
  and off-chain relays to a slash proposal; (b) a small view/callback. Discuss which.
• ROLE_DVT = keccak256("DVT") — align the roleId constant across both repos.

Roles / responsibilities after unification

• SuperPaymaster = economic/governance single source of truth: GToken stake,
  ROLE_DVT, slashing, liveness.
• AAStarValidator = cryptographic layer: BLS pubkey registry + aggregate
  verification; registration reads SuperPaymaster for the stake gate and binds
  nodeId → staked operator.
• Link = operator address, stored per nodeId.

Why not fully consolidate into SuperPaymaster

verifyAggregateSignature is the hot path (called per UserOp). Keeping pubkeys local
avoids a cross-contract read per signature (gas + tight coupling). We read the economic
layer once at registration, not per verification.

Post-implementation flow

operator EOA
 └─(1) SuperPaymaster: lock GToken → registerRole(ROLE_DVT)          [stake: single entry]
 └─(2) AAStarValidator.registerPublicKey(nodeId, pubkey) as operator
        → nodeOperator[nodeId]=operator
        → if requireStake: assert Registry.hasRole(ROLE_DVT,op) && lock≥minStake   [①②③]
 node co-signs UserOps  →  AAStarValidator.verifyAggregateSignature(nodeIds,…)
        → (optional) assert each nodeId's operator still active                     [liveness]
 misbehavior  →  DVTValidator: slash operator via nodeId→operator binding           [slashing]
 discovery    →  gossip roster {nodeId, apiEndpoint}; coordinator maps nodeId→operator to
                 check active/slashed state before including in a quorum

Open questions (for the challenge / finalization)

1. Slashing linkage — how does DVTValidator resolve nodeId → operator? Event-relay
   vs on-chain view vs storing the binding in SuperPaymaster instead.
2. Real-time liveness at verify — worth the per-verify gas, or off-chain pruning
   only (as DVTValidator already assumes)?
3. Deployed-contract reconciliation — repo AAStarValidator.sol (permissionless
   source) vs deployed AAStarBLSAlgorithm v0.20.0 (onlyOwner): which is canonical,
   and does this change target a redeploy?
4. roleId + minStake governance — confirm ROLE_DVT constant + who tunes minStake
   (Registry.configureRole, owner/governance).
5. One operator, many nodes? — does an operator run multiple nodeIds under one stake,
   or one stake per nodeId? Affects the binding cardinality.

Cross-repo: AAStarCommunity/YetAnotherAA-Validator (AAStarValidator changes) +
AAStarCommunity/SuperPaymaster (interface confirm + slashing linkage). This issue is
filed to both. Related: YetAnotherAA-Validator#157 (N-of-M), #50 (hardening).

[jhfnetboy]

Finalized after Codex adversarial challenge — Plan A v2

Codex challenged Plan A and found it not sound as-is (directionally right, but the
crypto active-set would be economically stale + Sybil-amplifiable). 7 required changes,
now folded into the finalized design below. (Codex session 019f2b91-9a1c-73b0-9943-75f0041cf5d3.)

The 7 fixes (each maps to a Codex finding)

1. Active-set lifecycle — stake loss MUST disable signing power (Critical).
   Registration-time check alone lets an operator unstake and keep co-signing forever.
   Fix: add an on-chain deactivation/sync path. A permissionless
   syncNode(nodeId) re-reads Registry role + getEffectiveStake ≥ minStake; if the
   operator no longer qualifies it flips the node inactive (removed from isRegistered
   for verification). Keepers/anyone can call it; slash/exit flows SHOULD call it.
   For high-value accounts, verifyAggregateSignature MAY additionally do a per-verify
   liveness read (opt-in, gas-priced). Minimum bar: stake loss is enforceable on-chain,
   not "checked once forever."

2. One stake ⇏ many nodes — prevent Sybil amplification (Critical).
   Enforce one active nodeId per operator in AAStarValidator
   (operatorNode[operator] one-to-one); a second node needs a second staked operator.
   (Alternative if multi-node is ever needed: require one GToken lock per nodeId, or make
   quorum count unique operators / stake-weight, never raw nodeId count.)

3. nodeId ownership — no squat/overwrite (High).
   nodeId is derived deterministically from the pubkey: nodeId = keccak256(pubkey).
   Removes caller-chosen collisions; overwrite of a registered node is rejected.

4. BLS proof-of-possession + operator authorization (High/Medium).
   Registration requires a PoP: a BLS signature by the registering pubkey over the
   operator address (domain-separated). Proves the operator controls the signing key and
   authorizes the binding — closes "who staked ≠ who signs." (Also underpins chore(deps): bump elliptic and solidity-coverage in /contracts/lib/openzeppelin-contracts #3.)

5. Slashing linkage is on-chain authoritative (High).
   AAStarValidator exposes nodeOperator(bytes32) view returns (address). DVTValidator /
   the slash path reads this view directly to punish the operator behind a misbehaving
   nodeId. NodeBound(nodeId, operator) events remain only as indexing hints.

6. Toggle is migration-safe (High).
   requireStake flip-to-ON is an activation boundary: pre-toggle bootstrap nodes are
   a separate class and are NOT auto-valid under stake — they must re-register (or be
   revalidated via syncNode) to enter the staked set. Owner cannot manufacture a
   permanent economic bypass by toggling.

7. Registry address governance hardened (Medium).
   The AAStarValidator→Registry pointer is set behind a timelock + multisig, emits a
   change event, and is intended to become immutable post-launch. Documented: during
   bootstrap the AAStarValidator owner is the trusted economic root.

Net design (Plan A v2)

• SuperPaymaster = economic single source of truth (unchanged core): GToken stake,
  ROLE_DVT, slashing. registerRole (permissionless + minStake) + getEffectiveStake /
  hasRole / getRoleConfig views are already sufficient.
• AAStarValidator = crypto layer + the binding: nodeId = keccak256(pubkey),
  nodeOperator[nodeId], operatorNode[operator] (1:1), PoP-verified registration,
  stake gate via Registry, requireStake toggle (migration-safe), syncNode
  deactivation, nodeOperator view for slashing.
• Hot-path verifyAggregateSignature stays local; stake liveness is enforced by
  syncNode deactivation (+ optional per-verify liveness), not per-signature cross reads.

Still-open (decide before coding)

• Per-verify liveness: opt-in per account, or rely on syncNode + epoch expiry only?
• syncNode incentive: who calls it / is there a slash-a-stale-node reward?
• Deployed AAStarBLSAlgorithm v0.20.0 (onlyOwner) vs repo AAStarValidator.sol:
  this targets a redeploy — confirm.

Verdict: with the 7 fixes, Plan A v2 is sound to implement. Next: forge-tested
contract changes (AAStarValidator-heavy; SuperPaymaster core unchanged) + onboarding
stake subcommand.

[jhfnetboy]

Plan A v3 — threat-model calibrated (don't over-defend)

Codex's v2 challenge was adversarial-by-default. Re-scoping each fix against what an
attacker actually gains in THIS system (is the attack profitable?), so we don't ship
heavy defenses against non-threats.

Threat model that resizes everything

The DVT is a second factor, not sole custody. The owner-auth gate
(eth_call isValidOwnerAuth) independently gates every sign, and the DVT only co-signs
the same userOpHash the owner already approved. So a malicious / Sybil / stale DVT
quorum cannot steal funds — it can only withhold (grief) or fake decentralization.
Economic security here protects liveness + a genuine M-of-N, NOT custody. That lowers
the bar on defenses aimed at "theft."

Re-scoped fixes

v2 fix	Profitable attack?	v3 decision
① per-verify liveness (stale stake)	Weak — 2nd factor, no theft; only griefing	Drop per-verify (over-defense, hot-path gas). Keep only a cheap permissionless syncNode(nodeId) that deactivates a node whose operator lost role/stake — hygiene, called on exit/slash or by keepers.
② one stake → many nodeIds	Medium — no theft, but breaks the "real M-of-N" claim	Keep one-active-node-per-operator (trivially cheap; prevents fake decentralization).
③ nodeId squat/overwrite	Weak — nodeIds aren't valuable	Keep nodeId = keccak256(pubkey) — not for the attack, but as a free simplification that removes the whole class + reject overwrite.
④ BLS proof-of-possession	This is crypto correctness, not economics — rogue-key in BLS aggregation	Verify first: the scheme already has the account sign the messagePoint (triple-verification). Confirm whether that already blocks rogue-key aggregation; add PoP only if it doesn't.
⑤ on-chain nodeOperator view for slashing	Free	Keep (expose the view; slashing reads it directly).
⑥ toggle migration-safe	Cheap to get right	Keep (toggle-on = activation boundary; bootstrap nodes re-register/revalidate).
⑦ Registry governance	Heavy timelock is likely over-engineering now	Use a Safe multisig: the operator/owner EOA is transferred to a Gnosis Safe multisig after initialization (jason's call). No heavy timelock initially; event on change; consider immutability later.

Net vs v2

• Dropped as over-defense: per-verify liveness (①), heavy timelock (⑦).
• Downgraded to "verify need first": BLS PoP (④) — keep only if the existing
  messagePoint-signature doesn't already cover rogue-key.
• Kept (cheap + defends a real problem — fake M-of-N / rogue-key / slashability):
  ② one-node-per-operator, ③ nodeId=keccak(pubkey), ⑤ nodeOperator view, ⑥ safe toggle.
• Governance: Safe multisig owner (operator EOA → Safe after init).

Verdict

Plan A v3 is the implementable target: keep the cheap defenses that protect
liveness + genuine decentralization + slashability; skip the expensive ones aimed at
theft, which the second-factor architecture already prevents. Next: (1) verify the ④
rogue-key question against the existing triple-verification, (2) implement on a branch
(AAStarValidator-heavy; SuperPaymaster core unchanged) with forge tests, (3) one more
Codex pass on the diff, (4) release, (5) full E2E.

[jhfnetboy]

Update: YetAnotherAA-Validator side implemented + merged (#165). SuperPaymaster core = NO changes needed.

Confirmed by reading SuperPaymaster contracts: the economic layer already has everything
the crypto layer needs. AAStarValidator now READS SuperPaymaster as the single source of
truth for stake — SuperPaymaster's Registry/GTokenStaking/DVTValidator are unchanged.

What AAStarValidator (YetAnotherAA #165, merged, 76/76 tests + 2-round Codex challenge) reads from here

• Registry.hasRole(ROLE_DVT, operator) (public mapping getter) — via IDVTRegistry.
• Registry.getEffectiveStake(operator, ROLE_DVT) — locked GToken (already delegates to
  GTokenStaking.getLockedStake).
• ROLE_DVT = keccak256("DVT") (from IRegistry.sol), minStake read as a local, owner/Safe-
  settable floor on the validator (kept off the Registry struct to avoid cross-contract struct
  coupling; governance tune via the validator's setMinStake).
• Permissionless self-registration already exists: Registry.registerRole(ROLE_DVT, msg.sender, roleData)
  enforces minStake + locks GToken. The onboarding flow: stake+registerRole HERE, then
  AAStarValidator.registerWithProof(pubkey, popPoint, popSig) there.

The only OPEN item on the SuperPaymaster side (not blocking): slashing linkage

To slash a misbehaving signer, DVTValidator needs nodeId → operator. AAStarValidator now
exposes nodeOperator(bytes32) → address (on-chain view) + emits NodeBound(nodeId, operator).
Decide how DVTValidator's slash path consumes it (read the view directly vs an attestation
flow). No SuperPaymaster code change is required to UNBLOCK the YetAnotherAA side; this is a
follow-up to close the slash-a-signer loop.

Threat-model note (why we did NOT add heavy on-chain checks here)

The DVT is a 2nd factor (can grief, not steal), so: no per-verify stake re-check on
AAStarValidator (keeper-called syncNode deactivates stake-losers); stake stays the single
source of truth here. Governance via a Gnosis Safe multisig (operator/owner EOA → Safe after init).

Refs: YetAnotherAA-Validator #163 / #165 (merged), aastar-sdk #270.