Skip to content

Deposit Admission And Allowlist Admin

Use this runbook when creating, removing, or rotating Phase-1 deposit admission authority in the current allowlist-admin/admission-intent model.

Operational Procedure

Purpose

Create exact deposit intents without confusing admission permissioning with custody/readiness or upgrade-governance validation.

When To Use

Use this for addAllowedDepositFor, batch admission, intent removal, and allowlistAdmin transfer. Do not use it to open permissionless admission; the current source has no runtime permissionless switch.

Required Authority

allowlistAdmin is required for intent creation, removal, transfer staging, and transfer cancellation. pendingAllowlistAdmin is required to accept a staged transfer.

Preconditions

  • Validator vault has been deployed and factory mapping is correct.
  • Withdrawal credentials are canonical execution credentials for the factory-registered vault.
  • Controller depositReadiness can be independently read and is expected to pass.
  • Governor policy assertions for deposit, factory, controller, claim gatekeeper, and beacon are expected to pass.
  • Current allowlistEpoch is recorded.

Inputs Required

  • Validator pubkey.
  • Withdrawal credentials.
  • Exact amountGwei; Phase 1 normal deposit is 32_000_000_000 gwei.
  • Exact authorizedDepositor address.
  • Current allowlistEpoch.
  • Reviewer approval for the tuple.

Step-By-Step Procedure

  1. Recompute the expected intent hash from pubkey, credentials, amount, authorized depositor, and current epoch.
  2. Confirm no matching consumedIntents entry exists.
  3. Submit addAllowedDepositFor or the batch equivalent from allowlistAdmin.
  4. Read isAllowedDepositIntentFor for the exact tuple.
  5. Provide the authorized depositor with the tuple and the custody/readiness evidence package.
  6. After deposit, confirm DepositIntentConsumedFor, DepositEvent, and consumedIntents state.

Independent Review Requirement

A second reviewer must check the tuple, especially the depositor address and withdrawal credentials. A correct allowlist event for the wrong caller or vault is an admission failure, not a harmless typo.

Abort Conditions

  • allowlistEpoch changed during review.
  • Authorized depositor is zero, unexpected, or not controlled by the intended party.
  • Withdrawal credentials do not decode to the factory-registered vault.
  • Custody/readiness evidence is missing or stale.
  • The requested action is a permissionless launch; that requires a governed implementation change.

On-Chain Pre-Checks

Read allowlistAdmin, pendingAllowlistAdmin, allowlistEpoch, allowedDeposits, consumedIntents, factory vault mapping, vault metadata, and controller readiness.

On-Chain Post-Checks

For intent creation, the exact intent should read active. For removal, it should read inactive without a consumed mark. For successful deposit, allowedDeposits should be false and consumedIntents true for the exact hash.

Events Or Logs To Monitor

  • DepositIntentAllowedFor.
  • DepositIntentRemovedFor.
  • DepositIntentConsumedFor.
  • AllowlistAdminTransferStarted.
  • AllowlistAdminTransferred.
  • AllowlistAdminTransferCancelled.

Evidence To Archive

Archive the tuple, epoch, intent hash, transaction hash, event logs, reviewer approval, vault-readiness evidence, and deposit transaction if consumed.

Escalation Path

Escalate tuple mistakes to admission operators, readiness failures to controller/factory owners, policy assertion failures to governance signers, and unexpected admin-transfer events to security incident response.