Author: Maulana Asykari Muhammad (@WeissCurry), Muhammad Zidan Fatonie (@mzf11125), Faisal Firdani (@zexoverz)
Type: Standards Track
Category: ERC
Status: Draft
Abstract
This ERC proposes an optional extension interface for ERC-4626 Tokenized Vaults that enables vaults to verify user acknowledgement of specific agreements before accepting new deposits or mint operations.
The extension introduces a standardized Consent Registry interface that allows vaults to verify whether an address has acknowledged a specific agreement identified by a cryptographic hash.
Consent records may represent acceptance of vault terms, risk disclosures, investment conditions, operational requirements, or other user acknowledgements.
This proposal does not modify the ERC-4626 accounting model. ERC-4626 vaults implementing this extension continue to expose the standard ERC-4626 interface while adding an optional consent verification layer before state-changing deposit operations.
Motivation
ERC-4626 standardizes tokenized vault functionality, including deposits, withdrawals, share minting, and redemption.
However, ERC-4626 does not define a mechanism for verifying whether a user has acknowledged information required before interacting with a vault.
Applications may require users to explicitly acknowledge:
-
vault terms;
-
risk disclosures;
-
investment conditions;
-
legal agreements;
-
operational policies.
Current implementations handle these requirements independently. This results in inconsistent consent storage models and different verification approaches across protocols.
This proposal introduces a common interface for consent-enabled ERC-4626 vaults while maintaining separation between vault accounting and consent management.
Specification
Consent Registry Interface
A Consent Registry stores and verifies consent records.
interface IERCXXXXConsentRegistry {
/\*\*
\* @notice Returns whether a user has valid consent
\* for a specific agreement.
\*/
function hasValidConsent(
address user,
bytes32 agreementHash
)
external
view
returns (bool);
/\*\*
\* @notice Returns the timestamp when consent was registered.
\*/
function consentTimestamp(
address user,
bytes32 agreementHash
)
external
view
returns (uint256);
/\*\*
\* @notice Registers consent for the caller.
\*/
function registerConsent(
bytes32 agreementHash
)
external;
event ConsentRegistered(
address indexed user,
bytes32 indexed agreementHash,
uint256 timestamp
);
}
Implementations MAY support additional consent creation mechanisms, including signatures and external attestations.
ERC-4626 Consent Extension Interface
ERC-4626 vaults implementing this extension MUST expose the Consent Registry and required agreement identifier.
interface IERC4626Consent {
/\*\*
\* @notice Returns the Consent Registry used by the vault.
\*/
function consentRegistry()
external
view
returns(address);
/\*\*
\* @notice Returns the agreement hash required for interaction.
\*/
function requiredAgreementHash()
external
view
returns(bytes32);
}
ERC-165 Interface Detection
Consent-enabled vaults SHOULD support ERC-165 interface detection.
Applications MAY use ERC-165 to determine whether a vault implements this extension.
Example:
type(IERC4626Consent).interfaceId
Deposit and Mint Verification
A vault implementing this extension MUST verify consent before executing:
deposit()
and:
mint()
The verification MUST check:
IERCXXXXConsentRegistry(consentRegistry())
.hasValidConsent(
receiver,
requiredAgreementHash()
);
Example:
function deposit(
uint256 assets,
address receiver
)
public
override
returns(uint256 shares)
{
require(
IERCXXXXConsentRegistry(consentRegistry())
.hasValidConsent(
receiver,
requiredAgreementHash()
),
"Consent required"
);
return super.deposit(
assets,
receiver
);
}
Withdrawal and Redemption Behavior
This extension MUST NOT restrict:
withdraw()
or:
redeem()
A user’s ability to withdraw existing assets MUST remain independent from future consent requirements.
Consent verification applies only to new vault interactions that create additional exposure.
Consent Creation
This proposal does not require a specific consent creation mechanism.
Implementations MAY support:
Direct On-chain Consent
A user may directly register consent:
registerConsent(
agreementHash
)
The registry MUST associate the consent record with:
msg.sender
EIP-712 Signature Consent
Implementations MAY support off-chain signatures.
Example structure:
struct Consent {
address user;
bytes32 agreementHash;
uint256 nonce;
uint256 deadline;
}
Signature-based implementations MUST include:
-
nonce protection;
-
deadline validation;
-
EIP-712 domain separation;
-
chain identification.
External Credentials and Attestations
Consent Registries MAY use external credential systems.
Examples include:
-
ERC-721 credentials;
-
ERC-1155 credentials;
-
non-transferable tokens;
-
attestation protocols.
Implementations MUST ensure that credentials resolve to:
-
a specific user;
-
a specific agreement hash.
Agreement Versioning
Agreements are identified using hashes.
Example:
agreementHash =
keccak256(documentBytes);
A URI MAY be stored as metadata.
The hash represents the exact agreement version accepted by the user.
When a vault updates its required agreement hash:
event AgreementUpdated(
bytes32 indexed agreementHash,
string agreementURI
);
previous consent records MAY no longer satisfy the vault requirement.
Users MUST provide consent for the new agreement version before depositing or minting additional shares.
Rationale
Separation of Responsibilities
ERC-4626 vaults are responsible for:
-
asset accounting;
-
share calculation;
-
deposits;
-
withdrawals.
Consent Registries are responsible for:
-
storing acknowledgements;
-
validating consent;
-
managing consent records.
This separation allows different consent mechanisms without modifying ERC-4626 accounting logic.
ERC-4626 Compatibility
This proposal does not replace existing ERC-4626 functions.
The following functions remain unchanged:
deposit()
mint()
withdraw()
redeem()
Consent verification is an additional requirement applied before specific state changes.
Agreement Identification
Using hashes instead of URLs prevents ambiguity caused by changing documents.
A URL may point to updated content, while a cryptographic hash identifies the exact accepted version.
Security Considerations
Signature Replay Protection
EIP-712 implementations MUST protect against replay attacks using:
-
nonces;
-
deadlines;
-
domain separation;
-
chain identifiers.
Credential Transferability
Consent credentials SHOULD NOT be transferable unless explicitly intended.
Transferable credentials may allow one address to use consent originally provided by another address.
Agreement Integrity
Implementations MUST verify the exact agreement hash required by the vault.
A document URL alone SHOULD NOT be treated as proof of consent.
Consent Expiration
Consent Registry implementations MAY support expiration policies.
If expiration exists, hasValidConsent() MUST return false after expiration.
Backwards Compatibility
Existing ERC-4626 vaults remain unaffected.
Applications interacting with consent-enabled vaults MAY detect the extension through ERC-165 and verify consent before submitting deposit or mint transactions.
Applications that do not use this extension require no changes.
Reference Implementation
A reference implementation SHOULD provide:
-
IERCXXXXConsentRegistry;
-
ConsentRegistry;
-
IERC4626Consent;
-
ERC4626ConsentVault.
The implementation MUST preserve ERC-4626 accounting behavior.
Open Questions
-
Should ERC-165 support become mandatory instead of recommended?
-
Should consent expiration rules be standardized?
-
Should agreement metadata follow an existing metadata standard?
-
Should Consent Registry implementations support batch consent verification?
Conclusion
ERC-XXXX introduces a standardized consent verification layer for ERC-4626 Tokenized Vaults.
The extension enables vaults to require user acknowledgement of agreements while preserving ERC-4626 compatibility.
The proposal separates consent management from vault accounting and allows implementations to use signatures, credentials, or attestation systems.
Copyright and Licensing
Copyright and related rights waived via CC0.