Launch App

    Type to search the documentation.

    Permissions & KYC

    How Kasu gates deposits: Didit for identity, a per-transaction signature minted by Kasu, manual allowlisting, blocklisting and role-based access.

    Kasu lending pools are permissioned. All Liquidity Providers must pass KYC verification before depositing. The system uses role-based access control for all administrative and operational functions.

    KYC Verification#

    Kasu uses Didit for identity verification, and mints the on-chain gating signature itself.

    How It Works#

    1. The Liquidity Provider completes Didit verification once; the outcome is recorded against their wallet by Kasu's KYC service
    2. The Liquidity Provider initiates a deposit through the Kasu frontend
    3. The frontend requests a deposit signature from the Kasu KYC signer service, passing the user's address and chain ID
    4. The service refuses unless the wallet's recorded status is verified; if it is, it signs over the user's current KasuAllowList nonce and returns the signature with a block expiration
    5. The frontend appends the signature and block expiration to the transaction calldata
    6. On-chain, KasuAllowList.verifyUserKyc() validates the signature via TxAuthDataVerifierUpgradeable
    7. If valid, the deposit proceeds

    Nothing about the deposit — amount, pool, tranche — is signed. The signature asserts only "this wallet is KYC-approved right now", bound to one chain, one user and one nonce.

    The signer configured on each KasuAllowList is KasuKycSigner, an ERC-1271 contract holding the address derived from Kasu's signing key. The key itself is held in a cloud KMS and is never exported. Holding it behind a contract makes a rotation one setSigningKey call per chain rather than a setNexeraIDSigner transaction on every deployment's allow list.

    Until 2026-08 this flow ran on Compilot (formerly NexeraID): their API minted the signature and their NexeraIDSignerManager sat in the signer slot. The signature scheme is unchanged — the contracts still extend Nexera's TxAuthDataVerifierUpgradeable — but the signer and the identity provider are now Kasu's and Didit's.

    Manual Allowlisting#

    The Kasu Admin can manually add addresses to the allowlist via KasuAllowList.allowUser(), bypassing the KYC process. This is used for institutional participants or special arrangements.

    Blocklisting#

    The blocklist supersedes all allowlisting and KYC verification. Any address on the blocklist is prevented from depositing, regardless of KYC status. The Kasu Admin manages the blocklist via KasuAllowList.blockUser() and KasuAllowList.unblockUser().

    Role-Based Access Control#

    All roles are managed through the KasuController contract, which extends OpenZeppelin's AccessControl. System-wide roles are granted/revoked by the Kasu Admin. Lending pool-specific roles are granted by the Pool Admin for each pool.

    See the Roles & Access Control page for the complete role matrix.

    Contracts Involved#

    • KasuController.sol — Role management, system pause/unpause
    • KasuAllowList.sol — KYC verification, manual allowlisting, blocklisting (extends TxAuthDataVerifierUpgradeable)
    • KasuKycSigner.sol — The ERC-1271 signer configured on each allow list; holds the address derived from Kasu's KMS key
    • vendor/nexera/ — Vendored NexeraID signature verification contracts