From cc41655ad85fc7a158cbb12ec52ae64838adc73f Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Thu, 30 Apr 2026 10:29:37 -0400 Subject: [PATCH 01/12] Add ERC: Vault Registrar Interface for Permissioned ERC-20 Vaults --- ERCS/erc-draft-vault-registrar.md | 249 ++++++++++++++++++++++++++++++ 1 file changed, 249 insertions(+) create mode 100644 ERCS/erc-draft-vault-registrar.md diff --git a/ERCS/erc-draft-vault-registrar.md b/ERCS/erc-draft-vault-registrar.md new file mode 100644 index 00000000000..4a6ddde8ef5 --- /dev/null +++ b/ERCS/erc-draft-vault-registrar.md @@ -0,0 +1,249 @@ +--- +eip: +title: Vault Registrar Interface for Permissioned ERC-20 Vaults +description: A standard companion contract interface enabling third-party protocols to register investor-bound vault contracts under an investor's compliance identity using explicit, revocable EIP-712 signed authorization. +author: Miguel Schneider (@MiguelSchneider) +discussions-to: https://ethereum-magicians.org/t/erc-proposal-vault-registrar-interface-for-permissioned-erc-20-vaults/27627 +status: Draft +type: Standards Track +category: ERC +created: 2026-01-30 +requires: 20, 712, 1271 +--- + +## Abstract + +This ERC 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. + +## Motivation + +Many permissioned ERC-20 tokens (e.g. regulated real-world assets) must maintain investor-level ownership attribution for regulatory compliance, lifecycle events, and corporate actions. + +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. This ERC standardizes the integration surface between protocols and permissioned-token ecosystems. + +## Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +### Overview + +A Vault Registrar is a standalone companion contract that permissioned ERC-20 ecosystems MAY expose. It 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. + +The high-level flow is as follows: + +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. + +### EIP-712 Authorization + +Vault authorization MUST be explicitly granted by the investor and MUST be revocable. The investor signs a structured EIP-712 message authorizing a specific operator to register vaults under their identity. + +**Domain:** + +``` +name = "VaultRegistrar" +version = "1" +chainId = +verifyingContract = +``` + +**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)" +) +``` + +Investors can invalidate all previously granted permissions to an operator on-chain via `invalidateOperatorPermission`, which increments the nonce and renders any outstanding signatures void. + +### Interface + +```solidity +interface IERC_VaultRegistrar { + + /// @notice Emitted when a vault is successfully registered under an investor's identity. + event VaultRegistered( + address indexed investor, + address indexed vault, + address token, + string investorId, + address indexed sender + ); + + /// @notice Emitted when a vault registration is revoked. + event VaultUnregistered( + address indexed investor, + address indexed vault, + address token, + string investorId, + address indexed sender + ); + + /// @notice Emitted when an investor invalidates all outstanding permissions for an operator. + 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 the authorization is missing, invalid, + /// or revoked, or if compliance checks fail. Intended to be called by authorized + /// protocol contracts as part of an atomic transaction. + /// @param vaultAddress The vault contract address to register. + /// @param investorWalletAddress The investor's wallet address that signed the authorization. + /// @param deadline Unix timestamp after which the signature is invalid. + /// @param signature EIP-712 signed permission from the investor. Supports both + /// EOA (ECDSA) and smart contract wallets (ERC-1271). + function registerVault( + address vaultAddress, + address investorWalletAddress, + uint256 deadline, + bytes calldata signature + ) external; + + /// @notice Check whether a vault is registered for a given investor. + /// @param vaultAddress The vault contract address. + /// @param investorWalletAddress The investor's wallet address. + /// @return True if the vault is currently registered under the investor's identity. + function isRegistered( + address vaultAddress, + address investorWalletAddress + ) external view returns (bool); + + /// @notice Revoke the registration of a vault. + /// @param vaultAddress The vault contract address. + /// @param investorWalletAddress The investor's wallet address. + function unregisterVault( + address vaultAddress, + address investorWalletAddress + ) external; + + /// @notice The permissioned ERC-20 token this registrar serves. + /// @return The token contract address. + function token() external view returns (address); + + /// @notice Returns the current nonce for an investor-operator pair. + /// Used to construct and verify EIP-712 authorization signatures. + /// @param investor The investor's wallet address. + /// @param operator The operator (protocol) address. + /// @return The current nonce value. + function operatorNonce( + address investor, + address operator + ) external view returns (uint256); + + /// @notice Invalidates all EIP-712 signatures previously granted by the caller to an operator. + /// Increments the nonce for the caller-operator pair, rendering any outstanding + /// signatures void. + /// @param operator The operator address whose permissions are being invalidated. + function invalidateOperatorPermission(address operator) external; +} +``` + +### Behavior Requirements + +- `registerVault` MUST revert if the provided signature is invalid, expired, or has been revoked via `invalidateOperatorPermission`. +- `registerVault` MUST revert if implementation-defined compliance checks fail. +- `unregisterVault` MUST emit a `VaultUnregistered` event upon success. +- `registerVault` MUST emit a `VaultRegistered` event upon success. +- `invalidateOperatorPermission` MUST increment the nonce and MUST emit `OperatorPermissionInvalidated`. +- Revocation MUST be enforced synchronously — a revoked authorization MUST NOT be usable in any subsequent call. + +## Rationale + +### Standalone Companion Interface + +This ERC is designed as a standalone contract interface rather than an ERC-20 extension for the following reasons: + +- 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. + +### EIP-712 Signed Authorization + +The choice to require explicit EIP-712 investor authorization rather than implicit protocol trust provides three key 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.** Investors can revoke authorization by invalidating the operator nonce. 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. + +### Relationship to ERC-4626 and ERC-7575 + +While this proposal involves vault contracts, it is orthogonal to ERC-4626 and ERC-7575. This ERC does not define vault accounting or asset semantics. It focuses exclusively on standardizing authorization of investor-bound vault addresses in permissioned ERC-20 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. + +## Backwards Compatibility + +This ERC introduces a new standalone interface and has no backwards compatibility issues with ERC-20 or any existing standard. Permissioned token contracts may adopt the Vault Registrar pattern without modifying their ERC-20 interface. + +This ERC is compatible with: + +- ERC-20 +- ERC-3643, ERC-1400, and custom permissioned token implementations +- ERC-1271 (smart contract wallet signatures) +- Regulated ERC-20 tokens, permissioned vault protocols, collateral and lending systems, and looping strategies + +## Reference Implementation + +A reference implementation is available at: +[https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833](https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833) + +## Security Considerations + +**Operator authorization scope.** Implementations SHOULD restrict which callers may invoke `registerVault`. Vault authorization SHOULD be treated as equivalent to investor authorization, as a registered vault will be able to hold and operate permissioned tokens on the investor's behalf. + +**EIP-712 signature validation.** Signatures MUST be validated against the correct domain separator and struct hash. Implementations MUST support both ECDSA (EOA) and ERC-1271 (smart contract wallet) signatures. Replay protection is provided by the nonce mechanism; implementations MUST verify the nonce matches the current value for the investor-operator pair. + +**Deadline enforcement.** Implementations MUST reject signatures with a `deadline` in the past. The `deadline` field MUST be checked against `block.timestamp`. + +**Revocation synchronicity.** Revocation via `invalidateOperatorPermission` MUST take effect immediately. A revoked authorization MUST NOT be accepted in any subsequent `registerVault` call within the same block or thereafter. + +**Reentrancy.** Implementations SHOULD follow the checks-effects-interactions pattern. `registerVault` is intended to be called within complex protocol flows; implementations should be safe against reentrancy attacks. + +**Denial of service.** Implementations SHOULD ensure that `registerVault` cannot be griefed by an adversary racing to invalidate an investor's nonce. Callers SHOULD construct transactions to minimize the window between signature issuance and on-chain submission. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From feab3e97043ac583fa3319b506d4cb99c9904716 Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Thu, 30 Apr 2026 16:38:46 +0200 Subject: [PATCH 02/12] Rename erc-draft-vault-registrar.md to 1713 --- ERCS/{erc-draft-vault-registrar.md => 1713} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename ERCS/{erc-draft-vault-registrar.md => 1713} (100%) diff --git a/ERCS/erc-draft-vault-registrar.md b/ERCS/1713 similarity index 100% rename from ERCS/erc-draft-vault-registrar.md rename to ERCS/1713 From fa17e4a11e8cf68f6e28f8c1a76e1365a835a69b Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Thu, 30 Apr 2026 16:52:33 +0200 Subject: [PATCH 03/12] Update and rename 1713 to erc-1713.md --- ERCS/{1713 => erc-1713.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename ERCS/{1713 => erc-1713.md} (99%) diff --git a/ERCS/1713 b/ERCS/erc-1713.md similarity index 99% rename from ERCS/1713 rename to ERCS/erc-1713.md index 4a6ddde8ef5..58337d156c8 100644 --- a/ERCS/1713 +++ b/ERCS/erc-1713.md @@ -1,5 +1,5 @@ --- -eip: +eip: 1713 title: Vault Registrar Interface for Permissioned ERC-20 Vaults description: A standard companion contract interface enabling third-party protocols to register investor-bound vault contracts under an investor's compliance identity using explicit, revocable EIP-712 signed authorization. author: Miguel Schneider (@MiguelSchneider) From 6f8811881000c2c37f9d50c216008d4de2a36d2a Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Thu, 30 Apr 2026 17:10:40 +0200 Subject: [PATCH 04/12] Update erc-1713.md --- ERCS/erc-1713.md | 44 ++++++++++++++++++++++++++------------------ 1 file changed, 26 insertions(+), 18 deletions(-) diff --git a/ERCS/erc-1713.md b/ERCS/erc-1713.md index 58337d156c8..ff515b1c075 100644 --- a/ERCS/erc-1713.md +++ b/ERCS/erc-1713.md @@ -13,13 +13,13 @@ requires: 20, 712, 1271 ## Abstract -This ERC 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. +This ERC 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. +The ERC is additive to [ERC-20], does not modify the [ERC-20] interface, and intentionally leaves identity and compliance logic implementation-defined. ## Motivation -Many permissioned ERC-20 tokens (e.g. regulated real-world assets) must maintain investor-level ownership attribution for regulatory compliance, lifecycle events, and corporate actions. +Many permissioned [ERC-20] tokens (e.g. regulated real-world assets) must maintain investor-level ownership attribution for regulatory compliance, lifecycle events, and corporate actions. 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. @@ -31,15 +31,15 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ### Overview -A Vault Registrar is a standalone companion contract that permissioned ERC-20 ecosystems MAY expose. It acts as a policy-enforcing registry. Before registering a vault under an investor's identity, it verifies: +A Vault Registrar is a standalone companion contract that permissioned [ERC-20] ecosystems MAY expose. It 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). +2. A valid investor permission exists (via [EIP-712] signed authorization). 3. Compliance rules are satisfied. The high-level flow is as follows: -1. An investor signs an EIP-712 authorization message granting a protocol permission to register vaults under their identity. +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. @@ -47,7 +47,7 @@ The high-level flow is as follows: ### EIP-712 Authorization -Vault authorization MUST be explicitly granted by the investor and MUST be revocable. The investor signs a structured EIP-712 message authorizing a specific operator to register vaults under their identity. +Vault authorization MUST be explicitly granted by the investor and MUST be revocable. The investor signs a structured [EIP-712] message authorizing a specific operator to register vaults under their identity. **Domain:** @@ -179,18 +179,18 @@ interface IERC_VaultRegistrar { ### Standalone Companion Interface -This ERC is designed as a standalone contract interface rather than an ERC-20 extension for the following reasons: +This ERC is designed as a standalone contract interface rather than an [ERC-20] extension for the following reasons: - 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. +The registrar acts as an adapter between protocols and permissioned [ERC-20] ecosystems. ### EIP-712 Signed Authorization -The choice to require explicit EIP-712 investor authorization rather than implicit protocol trust provides three key properties: +The choice to require explicit [EIP-712] investor authorization rather than implicit protocol trust provides three key 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. @@ -200,7 +200,7 @@ The choice to require explicit EIP-712 investor authorization rather than implic ### Relationship to ERC-4626 and ERC-7575 -While this proposal involves vault contracts, it is orthogonal to ERC-4626 and ERC-7575. This ERC does not define vault accounting or asset semantics. It focuses exclusively on standardizing authorization of investor-bound vault addresses in permissioned ERC-20 ecosystems. +While this proposal involves vault contracts, it is orthogonal to [ERC-4626] and [ERC-7575]. This ERC does not define vault accounting or asset semantics. It focuses exclusively on standardizing authorization of investor-bound vault addresses in permissioned [ERC-20] ecosystems. ### Non-Goals @@ -208,7 +208,7 @@ 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. +- 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. @@ -216,14 +216,14 @@ All compliance semantics remain implementation-defined. ## Backwards Compatibility -This ERC introduces a new standalone interface and has no backwards compatibility issues with ERC-20 or any existing standard. Permissioned token contracts may adopt the Vault Registrar pattern without modifying their ERC-20 interface. +This ERC introduces a new standalone interface and has no backwards compatibility issues with [ERC-20] or any existing standard. Permissioned token contracts may adopt the Vault Registrar pattern without modifying their [ERC-20] interface. This ERC is compatible with: -- ERC-20 -- ERC-3643, ERC-1400, and custom permissioned token implementations -- ERC-1271 (smart contract wallet signatures) -- Regulated ERC-20 tokens, permissioned vault protocols, collateral and lending systems, and looping strategies +- [ERC-20] +- [ERC-3643], [ERC-1400], and custom permissioned token implementations +- [ERC-1271] (smart contract wallet signatures) +- Regulated [ERC-20] tokens, permissioned vault protocols, collateral and lending systems, and looping strategies ## Reference Implementation @@ -234,7 +234,7 @@ A reference implementation is available at: **Operator authorization scope.** Implementations SHOULD restrict which callers may invoke `registerVault`. Vault authorization SHOULD be treated as equivalent to investor authorization, as a registered vault will be able to hold and operate permissioned tokens on the investor's behalf. -**EIP-712 signature validation.** Signatures MUST be validated against the correct domain separator and struct hash. Implementations MUST support both ECDSA (EOA) and ERC-1271 (smart contract wallet) signatures. Replay protection is provided by the nonce mechanism; implementations MUST verify the nonce matches the current value for the investor-operator pair. +**[EIP-712] signature validation.** Signatures MUST be validated against the correct domain separator and struct hash. Implementations MUST support both ECDSA (EOA) and [ERC-1271] (smart contract wallet) signatures. Replay protection is provided by the nonce mechanism; implementations MUST verify the nonce matches the current value for the investor-operator pair. **Deadline enforcement.** Implementations MUST reject signatures with a `deadline` in the past. The `deadline` field MUST be checked against `block.timestamp`. @@ -247,3 +247,11 @@ A reference implementation is available at: ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). + +[ERC-20]: ./eip-20.md +[EIP-712]: ./eip-712.md +[ERC-1271]: ./eip-1271.md +[ERC-4626]: ./eip-4626.md +[ERC-7575]: ./eip-7575.md +[ERC-3643]: ./eip-3643.md +[ERC-1400]: ./eip-1400.md From b6f7e7badc8b766344280fe4996f33139ff189e7 Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Thu, 30 Apr 2026 17:21:02 +0200 Subject: [PATCH 05/12] Update erc-1713.md --- ERCS/erc-1713.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/ERCS/erc-1713.md b/ERCS/erc-1713.md index ff515b1c075..727e4d3a15c 100644 --- a/ERCS/erc-1713.md +++ b/ERCS/erc-1713.md @@ -1,7 +1,7 @@ --- eip: 1713 -title: Vault Registrar Interface for Permissioned ERC-20 Vaults -description: A standard companion contract interface enabling third-party protocols to register investor-bound vault contracts under an investor's compliance identity using explicit, revocable EIP-712 signed authorization. +title: Permissioned Vault Registrar Interface +description: Interface for registering investor-bound protocol vaults under shared compliance identities via EIP-712 signed authorization. author: Miguel Schneider (@MiguelSchneider) discussions-to: https://ethereum-magicians.org/t/erc-proposal-vault-registrar-interface-for-permissioned-erc-20-vaults/27627 status: Draft @@ -13,7 +13,7 @@ requires: 20, 712, 1271 ## Abstract -This ERC 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. +This ERC introduces a 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. @@ -45,7 +45,7 @@ The high-level flow is as follows: 4. The registrar verifies the authorization and compliance rules. 5. If all checks pass, the vault is registered under the investor's identity. -### EIP-712 Authorization +### [EIP-712] Authorization Vault authorization MUST be explicitly granted by the investor and MUST be revocable. The investor signs a structured [EIP-712] message authorizing a specific operator to register vaults under their identity. @@ -188,7 +188,7 @@ This ERC is designed as a standalone contract interface rather than an [ERC-20] The registrar acts as an adapter between protocols and permissioned [ERC-20] ecosystems. -### EIP-712 Signed Authorization +### [EIP-712] Signed Authorization The choice to require explicit [EIP-712] investor authorization rather than implicit protocol trust provides three key properties: @@ -198,7 +198,7 @@ The choice to require explicit [EIP-712] investor authorization rather than impl **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. -### Relationship to ERC-4626 and ERC-7575 +### Relationship to [ERC-4626] and [ERC-7575] While this proposal involves vault contracts, it is orthogonal to [ERC-4626] and [ERC-7575]. This ERC does not define vault accounting or asset semantics. It focuses exclusively on standardizing authorization of investor-bound vault addresses in permissioned [ERC-20] ecosystems. @@ -227,8 +227,7 @@ This ERC is compatible with: ## Reference Implementation -A reference implementation is available at: -[https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833](https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833) +A reference implementation is available at https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833 ## Security Considerations From 5048294fe35951baad48efc8f504be5a193ad363 Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Thu, 30 Apr 2026 17:24:29 +0200 Subject: [PATCH 06/12] Update erc-1713.md --- ERCS/erc-1713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1713.md b/ERCS/erc-1713.md index 727e4d3a15c..7bce7c29234 100644 --- a/ERCS/erc-1713.md +++ b/ERCS/erc-1713.md @@ -227,7 +227,7 @@ This ERC is compatible with: ## Reference Implementation -A reference implementation is available at https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833 +A reference implementation is available at `https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833` ## Security Considerations From aa9fe55b98e18d865f390bf501a5d08cd26eeb01 Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Thu, 30 Apr 2026 17:37:08 +0200 Subject: [PATCH 07/12] Update erc-1713.md --- ERCS/erc-1713.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/ERCS/erc-1713.md b/ERCS/erc-1713.md index 7bce7c29234..2228f6f980b 100644 --- a/ERCS/erc-1713.md +++ b/ERCS/erc-1713.md @@ -208,7 +208,7 @@ 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. +- Replace or subsume [ERC-3643] or other permissioned token standards. - Mandate specific compliance checks or policies. - Define vault accounting, asset semantics, or identity models. @@ -221,13 +221,13 @@ This ERC introduces a new standalone interface and has no backwards compatibilit This ERC is compatible with: - [ERC-20] -- [ERC-3643], [ERC-1400], and custom permissioned token implementations +- [ERC-3643] and custom permissioned token implementations - [ERC-1271] (smart contract wallet signatures) - Regulated [ERC-20] tokens, permissioned vault protocols, collateral and lending systems, and looping strategies ## Reference Implementation -A reference implementation is available at `https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833` +A reference implementation is available at https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833 ## Security Considerations @@ -253,4 +253,3 @@ Copyright and related rights waived via [CC0](../LICENSE.md). [ERC-4626]: ./eip-4626.md [ERC-7575]: ./eip-7575.md [ERC-3643]: ./eip-3643.md -[ERC-1400]: ./eip-1400.md From 2662f22d23d34475380a06559bfdd3b441dc14dc Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Thu, 30 Apr 2026 17:46:06 +0200 Subject: [PATCH 08/12] Update erc-1713.md --- ERCS/erc-1713.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ERCS/erc-1713.md b/ERCS/erc-1713.md index 2228f6f980b..06af6157cb0 100644 --- a/ERCS/erc-1713.md +++ b/ERCS/erc-1713.md @@ -10,7 +10,6 @@ category: ERC created: 2026-01-30 requires: 20, 712, 1271 --- - ## Abstract This ERC introduces a 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. @@ -227,7 +226,7 @@ This ERC is compatible with: ## Reference Implementation -A reference implementation is available at https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833 +A reference implementation is available at `https://github.com/securitize-io/bc-vault-registrar/tree/feature/BC-1833` ## Security Considerations From 217d7d6ce0015c79a94d5c767c1bb8d40bb78573 Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Fri, 1 May 2026 15:01:16 +0200 Subject: [PATCH 09/12] Update ERCS/erc-1713.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- ERCS/erc-1713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1713.md b/ERCS/erc-1713.md index 06af6157cb0..b1741ac89fa 100644 --- a/ERCS/erc-1713.md +++ b/ERCS/erc-1713.md @@ -1,5 +1,5 @@ --- -eip: 1713 +eip: 8245 title: Permissioned Vault Registrar Interface description: Interface for registering investor-bound protocol vaults under shared compliance identities via EIP-712 signed authorization. author: Miguel Schneider (@MiguelSchneider) From 0fa762921e8c44ee78f51091c65726a419ba9761 Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Fri, 1 May 2026 15:01:35 +0200 Subject: [PATCH 10/12] Update ERCS/erc-1713.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- ERCS/erc-1713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1713.md b/ERCS/erc-1713.md index b1741ac89fa..0ca9200b8d0 100644 --- a/ERCS/erc-1713.md +++ b/ERCS/erc-1713.md @@ -3,7 +3,7 @@ eip: 8245 title: Permissioned Vault Registrar Interface description: Interface for registering investor-bound protocol vaults under shared compliance identities via EIP-712 signed authorization. author: Miguel Schneider (@MiguelSchneider) -discussions-to: https://ethereum-magicians.org/t/erc-proposal-vault-registrar-interface-for-permissioned-erc-20-vaults/27627 +discussions-to: https://ethereum-magicians.org/t/erc-8245-permissioned-vault-registrar-interface/27627 status: Draft type: Standards Track category: ERC From f52ffc9729cc0bd263f7d18d3c2877a803e24694 Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Fri, 1 May 2026 15:01:51 +0200 Subject: [PATCH 11/12] Update ERCS/erc-1713.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- ERCS/erc-1713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1713.md b/ERCS/erc-1713.md index 0ca9200b8d0..e3c7ddcde0f 100644 --- a/ERCS/erc-1713.md +++ b/ERCS/erc-1713.md @@ -1,6 +1,6 @@ --- eip: 8245 -title: Permissioned Vault Registrar Interface +title: Permissioned Vault Registrar description: Interface for registering investor-bound protocol vaults under shared compliance identities via EIP-712 signed authorization. author: Miguel Schneider (@MiguelSchneider) discussions-to: https://ethereum-magicians.org/t/erc-8245-permissioned-vault-registrar-interface/27627 From 88306f15c4e4190406100d59e0fedea13232b0bb Mon Sep 17 00:00:00 2001 From: MiguelSchneider Date: Fri, 1 May 2026 15:09:24 +0200 Subject: [PATCH 12/12] Rename erc-1713.md to erc-8245.md --- ERCS/{erc-1713.md => erc-8245.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename ERCS/{erc-1713.md => erc-8245.md} (100%) diff --git a/ERCS/erc-1713.md b/ERCS/erc-8245.md similarity index 100% rename from ERCS/erc-1713.md rename to ERCS/erc-8245.md