Skip to content

Conversation

@fdemiramon
Copy link

@fdemiramon fdemiramon commented Mar 17, 2025

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:

  1. Keyring Checker Contract Address: The address of the Keyring contract that performs credential verification
  2. Policy ID: The specific policy ID to check within Keyring
  3. User/Entity Address The address of the user or entity whose credentials need verification
    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:

  • Vault Configuration: KEYRING_CHECKER address and KEYRING_POLICY_ID are set as constants in the vault contract and become immutable after deployment
  • Credential Verification: the credential checks in the CommonVault contract, in the _operate function, before critical operations (deposits, withdrawals, etc.). We use a direct require statements rather than modifiers to avoid stack depth issues

Files added/modified:

  • Added: contracts/protocols/interfaces/IKeyringChecker.sol: created the file for the interface of the KeyringChecker, bringing the method to check a credential
  • Modified: contracts/protocols/vault/errorTypes.sol: added a custom error Vault__UserNotWhitelisted (id 31039) for credentials check not ok
  • Modified: contracts/protocols/vault/vaultTypesCommon/coreModule/constantVariables.sol: added the immutables KEYRING_CHECKER and KEYRING_POLICY_ID
  • Modifierd: contracts/protocols/vault/vaultTypesCommon/coreModule/mainOperate.sol: added the check of the credential, only if the KEYRING_CHECKER is not address(0)
  • Modified: contracts/protocols/vault/vaultTypesCommon/coreModule/structs.sol: added the two configuration items for Keyring
  • Modified: test/foundry/vaultT1/vault/vault.t.sol: added the tests

Concerns:

  • is the use of config the right way to bring these key information. Where in the deployment process should it be injected?
  • the tests are not running, hence the whole sustainability of the protocol cannot be checked with these modifications

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants