ERC Proposal: Vault Registrar Interface for Permissioned ERC-20 Vaults

ERCs
, ,
1

Summary

This proposal introduces a standard companion contract interface (“Vault Registrar”) for permissioned ERC-20 ecosystems.

The interface enables third-party protocols to register investor-bound vault contracts under the investor’s compliance identity, using explicit, revocable authorization granted by the investor via EIP-712 signed permissions.

The ERC is additive to ERC-20, does not modify the ERC-20 interface, and intentionally leaves identity and compliance logic implementation-defined.

Edit note (March 2026): This proposal has been substantially revised based on community feedback and learnings from real protocol integrations. Key changes include: renaming from “Vault Whitelister” to “Vault Registrar”, replacing implicit protocol trust with explicit EIP-712 signed investor authorization, generalizing the interface beyond simple whitelisting, and adding revocation support. See the reply below for a detailed changelog.

Problem Statement

Many permissioned ERC-20 tokens (e.g. regulated RWAs) must maintain investor-level ownership attribution for regulatory compliance, lifecycle events, and corporate actions.

However, common DeFi patterns — such as pooled contracts — aggregate balances across investors and obscure beneficial ownership.

A widely adopted alternative is investor-bound vaults: protocols deploy a dedicated vault contract per investor, the vault holds and manages the permissioned token on the investor’s behalf, and ownership attribution remains tied to the investor.

Today, authorizing such vaults requires bespoke, issuer-specific flows, forcing protocols to implement custom integrations for each permissioned token ecosystem.

Proposed Solution

This ERC defines a standardized companion contract interface (“Vault Registrar”) that permissioned ERC-20 ecosystems MAY expose.

The Vault Registrar acts as a policy-enforcing registry. Before registering a vault under an investor’s identity, it verifies:

  1. The operator (protocol) is authorized
  2. A valid investor permission exists (via EIP-712 signed authorization)
  3. Compliance rules are satisfied

High-level flow

  1. An investor signs an EIP-712 authorization message granting a protocol permission to register vaults under their identity.
  2. The protocol deploys a vault contract for the investor.
  3. The protocol calls the Vault Registrar, presenting the signed authorization.
  4. The registrar verifies the authorization and compliance rules.
  5. If all checks pass, the vault is registered under the investor’s identity.

The interface standardizes only the integration surface between protocols and permissioned-token ecosystems.

Note: While this proposal involves vault contracts, it is orthogonal to ERC-4626 / ERC-7575. This ERC does not define vault accounting or asset semantics, and focuses exclusively on standardizing authorization of investor-bound vault addresses in permissioned ERC-20 ecosystems.

Authorization Model: EIP-712 Signed Permissions

A central design choice in this proposal is that vault authorization must be explicitly granted by the investor and must be revocable.

Instead of implicitly allowing protocols to register vaults, the investor signs a structured EIP-712 message authorizing a specific protocol (operator) to register vaults under their identity. Investors can invalidate all previously granted permissions to an operator on-chain via invalidateOperatorPermission, which increments the nonce and renders any outstanding signatures void.

The authorization message is structured as follows:

Domain:

name              = "VaultRegistrar"
version           = "1"
chainId           = <deployment chain>
verifyingContract = <VaultRegistrar address>

Struct:

RegisterVault(
  address investor,
  address operator,
  address token,
  uint256 nonce,
  uint256 deadline
)

Type hash:

REGISTER_VAULT_TYPEHASH = keccak256(
  "RegisterVault(address investor,address operator,address token,uint256 nonce,uint256 deadline)"
)

This provides several important properties:

Clear user consent. The authorization message makes the permission explicit and user-visible. Investors cryptographically authorize vault creation rather than implicitly trusting protocol flows.

Revocable permissions. Because the authorization is a signed permission, investors can revoke it by invalidating the message or disabling the operator. This aligns with familiar wallet-based permission patterns.

Protocol lifecycle flexibility. Many real integrations involve collateral management strategies where new vaults may need to be created over time — for example, collateral rebalancing, leverage loops, liquidation protection, or strategy upgrades. The signed authorization allows those vaults to be created without requiring the investor to manually re-authorize every step.

Design Goals

  • Enable explicit, investor-authorized vault registration
  • Preserve investor-level beneficial ownership attribution
  • Support revocable permissions
  • Minimize integration friction for protocols
  • Support multiple permissioning models without standardizing identity
  • Avoid modifications to ERC-20 or existing permissioned token standards
  • Enable protocol interoperability across multiple regulated token ecosystems

Non-Goals

This proposal explicitly does not attempt to:

  • Standardize identity models, KYC, or accreditation logic
  • Define how investor identities are represented or stored
  • Replace or subsume ERC-3643, ERC-1400, or other permissioned token standards
  • Mandate specific compliance checks or policies
  • Define vault accounting, asset semantics, or identity models

All compliance semantics remain implementation-defined.

Interface Overview (Simplified)

interface IERC_VaultRegistrar {

    event VaultRegistered(
        address indexed investor,
        address indexed vault,
        address token,
        string investorId,
        address indexed sender
    );

    event VaultUnregistered(
        address indexed investor,
        address indexed vault,
        address token,
        string investorId,
        address indexed sender
    );

    event OperatorPermissionInvalidated(
        address indexed investor,
        address indexed operator,
        uint256 newNonce
    );

    /// @notice Register a vault under an investor's identity.
    /// @dev The caller (operator) must present a valid EIP-712 signed authorization from the investor.
    ///      Implementations MUST revert if authorization is missing, invalid, or revoked,
    ///      or if compliance checks fail.
    function registerVault(
        address vaultAddress,
        address investorWalletAddress,
        uint256 deadline,
        bytes calldata signature
    ) external;

    /// @notice Check whether a vault is registered for a given investor.
    function isRegistered(
        address vaultAddress,
        address investorWalletAddress
    ) external view returns (bool);

    /// @notice Revoke the registration of a vault.
    function unregisterVault(
        address vaultAddress,
        address investorWalletAddress
    ) external;

    /// @notice The permissioned token this registrar serves.
    function token() external view returns (address);

    /// @notice Returns the current nonce for an investor-operator pair.
    function operatorNonce(
        address investor,
        address operator
    ) external view returns (uint256);

    /// @notice Invalidates all signatures previously granted by the caller to an operator.
    function invalidateOperatorPermission(address operator) external;
}

The registerVault function is intended to be called by authorized protocol contracts as part of an atomic transaction. Implementations MUST revert if authorization cannot be completed.

The deadline parameter specifies the Unix timestamp after which the signature is invalid. The signature parameter carries the EIP-712 signed permission from the investor, and supports both EOA (ECDSA) and smart contract wallets (ERC-1271).

Why a Standalone Companion Interface

This ERC is intentionally designed as a standalone contract interface, rather than an ERC-20 extension:

  • Many permissioned tokens cannot be upgraded to add new methods
  • Compliance logic is often externalized for regulatory or operational reasons
  • Protocols prefer a predictable “call this contract during the flow” pattern
  • The design avoids imposing identity semantics on token contracts

The registrar acts as an adapter between protocols and permissioned ERC-20 ecosystems.

Compatibility

  • Fully compatible with ERC-20
  • Compatible with permissioned token standards such as ERC-3643, ERC-1400, and custom issuer implementations
  • Tokens may adopt this pattern without changing their ERC-20 interface
  • Compatible with regulated ERC-20 tokens, permissioned vault protocols, collateral and lending systems, and looping strategies

Security Considerations (High Level)

  • Implementations should restrict which callers may invoke registerVault
  • Vault authorization should be treated as equivalent to investor authorization
  • EIP-712 signatures must be validated carefully; replay protection is essential
  • Revocation must be enforced synchronously — a revoked authorization must not be usable
  • Implementations should be safe to call within complex protocol flows
  • Reentrancy and denial-of-service considerations apply

Reference Implementation

A reference implementation is available at:

Status and Next Steps

This proposal is shared for community feedback, particularly on the authorization model and whether the current level of abstraction is appropriate.

If there is alignment, the next step will be to submit this as a Draft ERC to the ethereum/ERCs repository.

Discussion

Feedback and discussion are welcome in this thread.

7 Likes
2

There are some who would object to the terms “whitelist” and “blacklist” instead preferring “allowlist” and “denylist”; it may be easier to get a standard approved using these more “neutral” terms.

Should the standard interface also contain a function to check current authorization status:

    event VaultAllowed(
        address indexed investor,
        address indexed vault,
        address indexed token,
        string investorId
    );

    function allow(
        address vaultAddress,
        address investorWalletAddress
    ) external;

    function isAllowed(
        address vaultAddress,
        address investorWalletAddress
    ) external view returns (bool);

Also should it contain a function to revoke permission with a corresponding event?

    event VaultDenied(
        address indexed investor,
        address indexed vault,
        address indexed token,
        string investorId
    );

    function deny(
        address vaultAddress,
        address investorWalletAddress
    ) external;
1 Like
3

My recently finalized proposal, ERC7656, enables the creator of an ERC-20 token to deploy an owned service linked directly to that token. Its core purpose is to allow tokens, NFTs, or wallets to be extended seamlessly with new functionalities, without requiring modifications to the original contract. Your proposal strikes me as an excellent and clear use case for this standard.
More info at https://erc7656.github.io/

4

Update: Vault Whitelister → Vault Registrar (March 2026)

We have substantially revised the original post above based on community feedback and learnings from real protocol integrations. Posting this reply so existing followers can see what changed and why.

What changed

Naming: “Vault Whitelister” → “Vault Registrar”. Following @dacian’s feedback on terminology, we renamed the contract and all associated functions. whitelist() is now registerVault(). We think “registrar” also better describes the contract’s role: it is a policy-enforcing registry, not simply an allowlist.

Authorization model: implicit trust → EIP-712 signed permissions. This is the biggest change. In the original proposal, the registrar implicitly trusted the calling protocol. Real integrations showed us this needs to be explicit and revocable. The investor now signs a structured EIP-712 message authorizing a specific operator to register vaults under their identity. This gives clear user consent, revocable permissions, and lifecycle flexibility (new vaults can be created for collateral rebalancing, leverage loops, etc. without requiring re-authorization at every step).

Revocation support. Directly addressing @dacian’s question — authorization is now a first-class concept with built-in revocation. Investors can invalidate a signed permission or disable an operator.

Generalized interface. The proposal moved from narrow “vault whitelisting” to a broader permissioned vault registration model, making it compatible with lending systems, collateral management, and looping strategies — not just simple deposits.

Regarding ERC-7656

@sullof — Thank you for flagging ERC-7656. The concept of deploying an owned service linked to a token is interesting and there could be complementarity. Our approach keeps the registrar as a standalone companion contract, which works well for tokens that cannot be upgraded. We would be happy to explore how the two patterns could work together for new deployments.

Multichain context

As additional validation: we have also implemented a Vault Registrar program for Solana (using transaction signer verification and CPI-based identity attachment rather than EIP-712). The two implementations confirm that the core pattern — a protocol vault operating under an investor’s compliance identity — is chain-agnostic. This gives us confidence that the ERC, while Ethereum-focused, captures a design that generalizes well.

1 Like