[DRAFT] Proposal for Keyring Network integration #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Important Note: This PR is not meant for immediate merging or to meet the highest quality standards. Its purpose is to gather feedback on the proposed implementation approach. For instance, the deployment of new vaults is broken with the current implementation and should be adapted as per the technical choices
Context
Keyring Network provides an on-chain credential verification system. This PR proposes integrating Keyring into the Fluid protocol to enable vaults to accept only users with verified credentials within the Keyring Network.
Keyring Integration Overview
For a smart contract to verify user credentials through Keyring, it requires three key pieces of information:
Keyring Checker Contract Address and Policy ID are expected to be constant/immutable.
With these three key information, the smart contract call the method, available on the Keyring Checker Contract Address:
function checkCredential(uint256 policyId, address entity) external view returns (bool);If this methods returns true, that means that the User/Entity has the right credential for this policyId in Keyring Network.
Proposed Implementation Approach into Fluid Protocol
We propose the following integration strategy, chosen for minimal codebase impact:
KEYRING_CHECKERaddress andKEYRING_POLICY_IDare set as constants in the vault contract and become immutable after deployment_operatefunction, before critical operations (deposits, withdrawals, etc.). We use a direct require statements rather than modifiers to avoid stack depth issuesFiles added/modified:
contracts/protocols/interfaces/IKeyringChecker.sol: created the file for the interface of the KeyringChecker, bringing the method to check a credentialcontracts/protocols/vault/errorTypes.sol: added a custom errorVault__UserNotWhitelisted(id 31039) for credentials check not okcontracts/protocols/vault/vaultTypesCommon/coreModule/constantVariables.sol: added the immutablesKEYRING_CHECKERandKEYRING_POLICY_IDcontracts/protocols/vault/vaultTypesCommon/coreModule/mainOperate.sol: added the check of the credential, only if theKEYRING_CHECKERis notaddress(0)contracts/protocols/vault/vaultTypesCommon/coreModule/structs.sol: added the two configuration items for Keyringtest/foundry/vaultT1/vault/vault.t.sol: added the testsConcerns: