feat(cct-sdk): Add transfer admin evm op

[apedrob]

What

• Add transferAdmin to EVMTokenManager, encoding transferAdminRole; two step: newAdmin has to call acceptAdmin to finish the hand-off

Why

• Lets an existing administrator assign the role to someone else
• Pre-tx read tells apart three situations that would otherwise all surface as the same revert: the token is not registered, it is registered but still waiting to be accepted, or the caller is simply not the administrator; registration state is checked before comparing sender, so a zero address sender cannot match an unregistered token's zero administrator and slip through

Testing

• Unit tests cover the encoding, all three rejection messages and the wallet binding

Notes

• This is the registry admin role, which is separate from a pool's transferOwnership

[vercel]

You must have Developer access to commit code to Chainlink Labs on Vercel. If you contact an administrator and receive Developer access, commit again to see your changes.

Learn more: https://vercel.com/docs/accounts/team-members-and-roles/access-roles#team-level-roles

[aelmanaa]

✅ APPROVE — EVM transferAdmin op (bf7feb3)

Reviewed for authorization checks, three-state registration validation, and test coverage. Strong work — the op pairs with registerAdmin to complete the two-step admin handoff, disambiguates three error cases, and catches a critical zero-address bypass regression.

---

Strengths

Three-state registration pre-flight with explicit error disambiguation

• Not registered (administrator = zero): Clear error "token is not registered in the TokenAdminRegistry"
• Pending acceptance (pendingAdministrator ≠ zero): Clear error "registration still pending acceptance by {address}; that address must call acceptAdmin first"
• Already registered (administrator ≠ zero): Checks if sender equals administrator, with error "must be the current token administrator"
• Registration state is checked BEFORE comparing against sender, preventing a critical bypass

Critical regression guard: zero-address sender on unregistered token

• Without the state-first guard, a zero sender would compare equal to an unregistered token's zero administrator and silently build a transferAdminRole tx for an unregistered token (security issue)
• Regression tests explicitly cover both branches (not-registered + pending-acceptance) with zero sender
• State check happens first, independently of sender, preventing the bypass

Pair-wise symmetry with registerAdmin

• Both are two-step flows: registerAdmin proposes, acceptAdmin completes
• Both use senderBoundToWallet to prevent authorization leaks
• Both have optional sender in execute (defaults to wallet), required in generate
• Both pre-flight the authorization before encoding

Version-stable encoding

• transferAdminRole(token, newAdmin) is version-identical across v1.5–v2.0
• No version dispatch needed (unlike some other ops)
• TAR resolved from any compatible contract (registry, Router, OnRamp, OffRamp, TokenPool)

Clear authorization boundary

• Doc explicitly distinguishes registry admin role (this op) from pool owner (transferOwnership)
• Common practice: same EOA/multisig for both roles, but roles live on separate contracts
• Two roles transferred independently — confusion not possible with clear naming

Test coverage (301 lines, 16+ test cases)

• Calldata golden vector: transferAdminRole(token, newAdmin) encoded against known interface
• Selector validation: TAR discovery confirmed
• All three rejection states with state-first guard regression tests (zero sender + not-registered, zero sender + pending)
• Missing sender rejection (required for generate)
• Wallet binding: reject non-signer, reject wallet≠sender divergence
• Default sender to wallet address in execute

---

Per-Scenario Analysis

Happy path: current admin transfers role

• Registry read confirms administrator ≠ zero (registered)
• Sender matches administrator
• Encodes transferAdminRole(token, newAdmin)
• ✅ Verified in test "encodes transferAdminRole to discovered TAR"

Rejection: not registered

• Administrator = zero
• Error: "token is not registered in the TokenAdminRegistry"
• ✅ Verified; explicit test "rejects token that is not registered"

Rejection: pending acceptance

• Administrator = zero, pendingAdministrator ≠ zero
• Error: "registration still pending acceptance by {address}; that address must acceptAdmin"
• ✅ Verified; explicit test "distinguishes pending from not-registered"

Rejection: sender not current admin

• Administrator ≠ zero, sender ≠ administrator
• Error: "must be the current token administrator ({administrator})"
• ✅ Verified; explicit test "rejects sender not current administrator"

Regression guard: zero sender on unregistered token

• State-first check catches it: administrator = zero → "not registered"
• Error surfaces before sender !== administrator comparison (which would succeed, silently)
• ✅ Verified; explicit regression test "rejects zero-address sender on unregistered token"

Regression guard: zero sender on pending token

• State-first check catches it: administrator = zero, pendingAdministrator set → "still pending"
• ✅ Verified; explicit regression test "rejects zero-address sender on pending token"

---

Calldata Verification

Golden vector: transferAdminRole(token, newAdmin)

• Token parameter serialized first, newAdmin second (matches TAR ABI order)
• Selector validated against cached TAR interface
• ✅ Verified against interfaces.TokenAdminRegistry in test

---

Wallet Binding & Authorization Leak Prevention

Uses senderBoundToWallet (from PR #333's EVMOperation enhancement):

• generate() requires explicit sender (can be any address; used for offline flows)
• execute() optional sender defaults to wallet address (only address that can satisfy the admin check for a signed tx)
• If sender is given to execute, it must match wallet address or throws before signing
• Prevents the leak where pre-tx checks authorize one address, signing wallet is different

---

Parameter Semantics

tokenAddress — Token whose registry admin role is being handed over
newAdmin — The proposed new administrator; must separately call acceptAdmin to accept
address — Contract to resolve TAR from (can be TAR, Router, OnRamp, OffRamp, or TokenPool)
sender — Current registry administrator; required for generate, optional for execute (defaults to wallet)

---

Nits (non-blocking)

• Example parity: Both generateUnsignedTransferAdmin and transferAdmin examples are clear; inline example in the op class docstring might show the three rejection scenarios (pedagogical, not needed for merge)

• Zero-address bypass context: The regression test comment is excellent ("the guard compared administrator !== sender first"), but a reference link to the registerAdmin PR (#333) could clarify why this pattern matters (senderBoundToWallet also added there)

---

npm run check status

✅ Exit 0 — no type errors.

---

Verdict

APPROVE. All three registration states are disambiguated with clear errors, the zero-address bypass regression is caught and tested, pre-tx validation prevents ambiguous on-chain reverts, and test coverage is comprehensive. The op correctly completes the two-step admin handoff pair with registerAdmin. Ready for merge.

[aelmanaa]

✅ Feedback addressed (commit 7485c06):

1. ✅ newAdmin = ZeroAddress behavior documented — Updated TransferAdminParams.newAdmin JSDoc to note:

   "Pass {@link ZeroAddress} to cancel any pending transfer — the pending proposal is discarded without accepting the role."

   • Tested live on Sepolia: cancel tx

2. ✅ Role distinction warning added to execute method — Updated transferAdmin() JSDoc in evm/index.ts to include:

   "This is the registry's ADMIN role — distinct from a pool's Ownable2Step owner (see {@link transferOwnership}); do not confuse the two."

   • Now consistent with generateUnsignedTransferAdmin() documentation
   • Provides unified guidance across both method variants

Type check: ✅ npm run check exit 0