# Keyring Pro

## 1. **Use a test Policy**

Use our Keyring Pro Test Policy (ID: 6 [see here](https://sandbox-titan.app.keyring.network/policies/keyring-pro-test-policy)). It includes standard checks to test individual and business onboardings. Policy setup:

1. **Data sources**: using you own compliance desk. 
2. **Rule**: 
   * Individual users: valid according to the policy owner response.
   * Business users: valid according to the policy owner response.
3. **Other parameters**: 
   * Refresh rate: 1 year

{% hint style="info" %}
Note that we are not simulating Know-Your-Wallet checks on Sepolia. 
{% endhint %}

🔗 Address of the deployed Sepolia [Policy Manager contract.](https://sepolia.etherscan.io/address/0x2B23ebb40c2FB68bef09F62616451abb59BB7689)

## **2.** On-chain Permissioning

Hook your chosen functions with permissioning reading from the Keyring contract, for Test Policy 6. The hook uses a `view` function on the Cache, which maps wallet addresses to Policy IDs. Here, it will verify that a user wallet has valid credentials for Policy 6. 

```solidity
if(!keyring.checkCredential(policyId, msg.sender)) {
    revert Unauthorized();
}
```

{% hint style="success" %}
Given the KeyringCredentialView contract's `checkCredential` function is view-only, it can be integrated into state-changing and non-state-changing code blocks. 
{% endhint %}

The Keyring view function `checkCredential` will return a boolean value if the given address (in this case the `msg.sender`) is authorised or not for the given Policy ID.

<details>

<summary>Example: Euler v2</summary>

In our Euler v2 example, we want to create an ERC4626-compatible vault where any base asset deposit or withdrawal is permissioned using Keyring Cache.

Note that typically, it would be wise to guard the base ERC4626 functions, `mint` / `redeem` / `deposit` / `withdraw` to prevent direct interaction with the pool.&#x20;

We also want to gate the `transfer` / `transferFrom` ERC20 methods to prevent secondary vault token transfers.

***

**Part 1: Hook initialisation**. This modifier can be added to any function. It guards the execution so that only whitelisted wallets can perform the permissioned action.

```solidity
 modifier checkKeyring() {
    if (!keyring.checkCredential(policyId, getAddressFromMsgData())) {
        revert KeyringCheckFailed();
    }
    _;
}
```

Code example available here: <https://github.com/euler-xyz/euler-vault-kit/blob/feat/poc-keyring/src/Hooks/KeyRingHook.sol>&#x20;

***

**Part 2: Include hook in relevant functions**. In our example, we would guard the following ERC4626 functions: `mint` / `redeem` / `deposit` / `withdraw`, and the `transfer` / `transferFrom` ERC20 methods to prevent secondary vault token transfers.

Here's an example of how it's done for the `deposit` function:

```solidity
function deposit(uint256 amount, address receiver) public override checkKeyring nonReentrant returns (uint256) {
    return super.deposit(amount, receiver);
}
```

</details>

### Useful links

🔗 [Keyring](https://etherscan.io/address/0xD18d17791f2071Bf3C855bA770420a9EdEa0728d) Contract deployed on Sepolia

## 3. Test User Flow

Test the end-to-end user journey on the Keyring app.&#x20;

{% hint style="info" %}
You'll need Sepolia ETH to create your credentials. You can get some here:&#x20;

🔗 [Alchemy](https://www.alchemy.com/faucets/ethereum-sepolia)

🔗 [Infura](https://www.infura.io/faucet/sepolia)

🔗 [Mining faucet](https://sepolia-faucet.pk910.de/)
{% endhint %}

Navigate to <https://sandbox-titan.app.keyring.network/> and test the user journey with your own Sepolia test environment. Complete the mock onboarding for Policy 6.

{% hint style="success" %}
We are mocking the checks so you don't need to input real data for onboarding, and you can also "skip onboarding" to yield a successful onboarding response and test the flow.&#x20;
{% endhint %}