On-Chain Non-Custodial Asset Management Infrastructure
karpatkey’s infrastructure has set the stage for a future where asset management is transparent, secure, efficient—and most importantly—non-custodial and trust-minimised.
By combining cutting-edge tools with decentralised principles, karpatkey’s tools empower asset owners and managers, ensuring funds' safety while maximising operational efficiency.
karpatkey has developed a sophisticated infrastructure using a simple yet effective concept: on-chain permissions policies for seamless interaction with DeFi protocols.
This non-custodial and trust-minimised operational setup illustrates karpatkey's core asset management pipeline: asset managers control a Manager Wallets (Safe) assigned with a manager role, which enables them to execute transactions on behalf of the Portfolio Wallet (Safe) within the scope of the On-Chain Permissions Policy.
An Overview of karpatkey’s Tooling
Let's introduce the family of tools and modules in karpatkey’s infrastructure, a technology stack leveraging the permissions policy principle.
karpatkey’s execution infrastructure is built on top of:
Safe Smart Account: account abstraction leading solution developed by Safe, a sister project incubated in Gnosis.
Permissions Policy Building:
Roles Modifier: Zodiac smart contract enforcing the permissions policies developed by Gnosis Guild, a sister project incubated in Gnosis.
DeFi Kit: Safe + Roles Modifier permissions policy builder for DeFi protocol interactions.
Transaction Building:
Roles Royce: SDK facilitating the building of transactions to interact with DeFi protocols through Safe + Roles Modifier following the DeFi Kit permissions.
DeFi Repertoire: list of predesigned and composable yield-optimising and risk management-related financial strategies built with Roles Royce;
Execution:
Execution App: application interface enabling asset managers to interact with Dapp UIs and to execute DeFi Repertoire strategies.
Guardians: automated bots implementing DeFi Repertoire strategies.
In the following sections, we dive into these tools, their concepts and implementation and how they are layered. We’ll culminate in the execution tooling that streamlines karpatkey’s asset management operations.
Permission Policy Building
Roles Modifier: Permissions policy enforcing smart contracts
The Roles Modifier allows the definition and enforcement of fine-grained, role-based access control for enabled roles for a Safe. By assigning roles with specific permissions to approved addresses, asset owners can grant third-party execution access while maintaining ownership.
When a role is assigned to an address, the latter can execute the specific transactions allowed by that role’s permissions policy on behalf of the safe holding the assets, through the Roles Modifier contract. A given role can be assigned to multiple addresses, and various roles can be assigned to any given address.
More specifically, a permissions policy consists of:
a set of allowlisted contract addresses;
a set of allowlisted functions within these allowlisted contract addresses;
a function-specific set of argument constraints.
In executing a transaction, the contract scopes the sender's address, the target contract address and the encoded calldata, and the transaction will not be reverted only if all of these satisfy the constraints enforced by the permission in the corresponding role’s permissions policy.
This transaction was executed through the Manager Role and Permissions Policy in the Manager Safe owned by karpatkey’s asset managers, which deposited DAI from the ENS DAO Portfolio Safe into Maker’s DSR.
DeFi Kit: Permissions builder
Defining permissions requires a deep understanding of the underlying protocols, contract architecture, and security implications. The DeFi Kit aids in this endeavour by providing a set of carefully designed permissions covering interactions with DeFi protocols, thereby facilitating the creation of custom permissions policies.
These permissions have been crafted to ensure the owner's custody of the assets cannot be jeopardised, even by a malicious asset manager, while maximising the scope of actions allowed within these custody constraints.
One of DeFi Kit’s core functionalities is providing the means to build custom Manager Role permissions policies seamlessly. To achieve this, it defines standard Actions that abstract over implementation-specific differences between protocols. This allows for the creation of permissions policies in terms of Protocol Actions.
Actions, such as deposit, borrow, swap, etc., represent bundled permission sets that enable various elementary interactions with protocols. Essentially, a permissions policy can be crafted by selecting a suitable set of Protocol Actions.
As an example, this Aave v3 deposit action provides the policy configuration to enable the properly scoped calling of the following contract methods:
approve(address,uint256) in the target token contract;
supply(address,uint256,address,uint16) in the Pool contract;
setUserUseReserveAsCollateral(address,booL) in the Pool contract; and
withdraw(address,uint256,address) in the Pool contract.
Via the Permissions Policy Manager UI, asset owners can either construct and deploy a permissions policy, or asset managers can create and propose one for approval and deployment by the asset owners.
Transaction Building
Roles Royce: SDK to interact with DeFI protocols
The Roles Royce library is an SDK that provides primitives to interact with DeFI protocols on behalf of a Safe and through the Roles Modifier’s role-based access. It is a library that facilitates building Safe and Roles Modifier DeFi protocol transactions and their execution.
Also, these transactions are built following the DeFi Kit permissions’ argument constraints. Essentially, this SDK offers a simplified API for creating and executing role-based protocol transactions permitted by the DeFi Kit permissions.
This example demonstrates the use of the Roles Royce primitive to create a transaction for repaying DAI debt in a Maker Vault via the DSP Proxy, where any fixed arguments comply with the DeFi Kit permission constraints.
DeFi Repertoire: Pre-designed and composable execution strategies
DeFi Repertoire is a set of carefully designed execution strategies built with the Roles Royce SDK. It is quintessentially a list of parameterised transactions to interact with DeFi protocols on behalf of a Safe and through the Roles Modifier’s role-based access.
Strategies range from simple swaps to complex transaction batches encompassing multiple steps and actions, e.g. executing a carry trade by depositing collateral, borrowing an asset, swapping, providing liquidity and staking the position.
Also, this list of strategies intends to be as comprehensive as possible, containing numerous variations to address the multitude of scenarios within the DeFi ecosystem. For instance, among the Lido disassembling strategies that DeFi Repertoire provides for a stETH holding position, we have:
swapping stETH for ETH on CowSwap;
swapping stETH for ETH on Curve’s ETH/stETH pool; and
wrapping stETH, and swapping wstETH for WETH on Balancer’s WETH/wstETH pool.
Finally, the permissions needed for each of these strategy elements in DeFi Repertoire are also provided by DeFi Kit through specifically ad-hoc designed minimal sets of permissions tailored per strategy.
Execution Tooling
Our Execution Tooling aims at enhancing operational efficiency and streamlining asset management processes. This toolset comprises two key components:
Execution App: manual execution triggered by asset managers through a UI.
Guardians: automated execution implementing risk management and operational efficiency streamlining strategies.
Execution App: UI to execute DeFi Repertoire strategies
The Execution App uses multisignature-based execution through the Manager Safe and Safe Transaction Service using two different pipelines:
Dapps pipeline: powered by the Zodiac Pilot technology, asset managers can interact with protocol UIs through a Dapp UIs’ wrapper that builds the role-based transactions and re-routes them to the Manager Safe. This pipeline enables asset managers to interact seamlessly with the familiar UIs they are accustomed to.
DeFi Repertoire pipeline: a specialised application with a user interface tailored for submitting DeFi Repertoire strategies directly to the Manager Safe's transactions queue. This application also mitigates the Dapp UIs dependence during hectic conditions, when a protocol's UI may malfunction or suffer from a DNS attack.
For simpler and swifter execution patterns, the Execution App also allows for the execution of DeFi Repertoire strategies with no manual signing or multisignature process, enabling swift execution of the carefully designed strategies.
This feature enables asset managers to craft roles with tailored permissions policies allowlisting custom subsets of strategies from the DeFi Repertoire menu. These permissions policies are very narrowly scoped, built with the specifically ad-hoc designed minimal sets of permissions per strategy provided by DeFi Kit. By assigning these roles to dedicated signer EOAs, asset managers can swiftly execute these strategies without the multisignature process overhead.
The use of multiple-role dedicated signers aims to mitigate the risk of granting excessive power to a single signer, minimise the potential for risky entanglements between permissions policies, and maintain a clearer record for accounting purposes.
Examples of these simpler roles include position disassembling, harvesting, carry-trade, anti-liquidation, and more.
Guardians: Automated Bots executing DeFi Repertoire strategies
Guardians serve as the vessels of karpatkey’s automated execution. They are keeper bots that implement automated risk management strategies and handle execution tasks. Specifically, Guardians enable the automation of day-to-day execution aspects or autonomously disassemble or modify positions potentially at risk in response to specific triggers. These triggers include suspected exploits, anomalous pool behaviour, and rapidly decreasing collateral ratios, among other predefined risk scenarios.
The deployment of a Guardian comprises establishing the logic that drives the triggering conditions, as well as the DeFi Repertoire strategies it will execute in response. A guardian role is created with a permissions policy crafted via DeFi Kit, containing the minimal set of permissions necessary for the established DeFi Repertoire strategies. This role is assigned to a guardian dedicated signer EOA for automated programmatic single-signature execution.
The core methodology for the Guardians’ algorithms and triggering conditions relies upon the decision theory framework modelling a system (e.g. position; protocol) in terms of a state vector and a finite state space representation, along with a finite set of parameterised actions, transforming one state into another. Namely, by selecting a suitable set of variables (e.g. collateral ratio; price; any on-chain/off-chain metric) to describe the system's state, the multidimensional vector space is partitioned into a finite number of states. Subsequently, an action (i.e. the execution of a DeFi Repertoire strategy) might be assigned as the response to identifying each state.
This way, Guardians enable asset managers to deploy pre-designed and automated execution strategies tailored to navigate different risk scenarios.
