Unstacked is a series of high-level technical teardowns, which unpack the kpk stack for non-custodial management of digital assets. Each article dives into core technological advancements at the cutting edge of onchain asset management, and how kpk is utilising these to drive forward industry best practices.
The face of DeFi security is changing rapidly. The good news is that smart contract exploits are fading away, as the industry consolidates around well-established best practices. The bad news is they’re being replaced by offchain injections of malicious calldata—like the recent $1.5 billion Bybit attack delivered through a UI exploit. Unfortunately, the surface area for potential attacks only seems to be growing…
When exploits like this occur, they often trigger a wave of enquiries to service providers like kpk about our emergency preparedness for similar attacks. Fortunately, in this case, our answer is a straightforward one:
kpk’s Permissions Layer eliminates any single point of failure that could otherwise leave assets susceptible to malicious calldata attacks.
This is a bold claim, but one that’s borne out in the technical details. What does that really mean in practice? Let’s explore. 👇
Permissions Layer
Permissions are rules that determine whether or not actors are entitled to perform specific actions. From denying all entry, to tightly constraining the access that’s granted, effective onchain permissions prevent unexpected actions (and any harms they could cause).
In smart contracts, permissions can be thought of as sophisticated decoders of calldata. They sit between the caller and the implementation of their call, reviewing the calldata and apply logic to determine if implementation is allowed. Beyond blocking addresses or gatekeeping functions, permissions contracts discern all the information the caller is submitting, allowing for precise logic to be applied.
This means that the only route to pass malicious data through our kpk “Permissions Layer” is to achieve two separate points of failure, including both the malicious transaction and a pre-approved permission for its calldata.
If an amount over the approved value is submitted, it will be automatically rejected. If the transaction includes assets outside the agreed whitelist, it will be rejected. And, if the transaction contains unexpected instructions to drain the account, it will be rejected. Only if the logic is pre-approved and fits within the specific parameters of our permissions can it be approved.
This Permissions Layer forms the base of our technology stack, through which all managed transactions flow. This layer is composed not just of onchain permissions contracts, but also of sophisticated tooling for building, configuring and adjusting permissions easily, with minimal room for error.
Our typical workflow is to collaborate with partners to define the assets, protocols and chains through which funds will be managed. This helps to identify the specific permissions needed for the desired management, and to group them into tailored “onchain permissions policies”. The partner’s portfolio account then grants the relevant permissions to kpk’s manager account, allowing us to prepare, submit and execute the permitted actions.
Roles & Sub-roles Modifier
Our Permissions Layer builds on top of Gnosis Guild's Zodiac Roles Modifier—a standardised permissions contract built for Safe smart accounts.
Roles Modifier allows users to configure and assign granular permissions to other accounts to act on their behalf. It allows different policies to be assigned to specific roles (e.g. the “Treasury Manager” role). Any number of addresses can be mapped to a given role, and any number of roles can be made and operated in tandem. This provides a complete and flexible primitive that can be used for all kinds of situations involving account management.
However, the process of creating and operating permissions with Roles Modifier can quickly become daunting, because the technology is incredible flexible and open-ended. Though interfaces and tooling exist, it’s easy to make mistakes designing new permissions for yourself. Users must understand not only the precise smart contracts and parameters they want to grant permissions for, but also how Roles Modifier works at a smart-contract level.
The goal of kpk’s Permissions Layer is to harmonise this experience for onchain asset management use cases, providing standardised permissions templates and easy-to-use tools to build and manage them. We’ve distilled years of our own experience into far simpler processes and tools, that make the process manageable for a far wider array of audiences.
One example is our evolution of the Roles Modifier design into kpk’s Sub-roles Modifier. A tradeoff with Roles Modifier is that each change in permissions must be signed off by the managed account, which are often large multi-sig wallets requiring many signatures. The counterpoint to the strong security this provides is that it’s simply not feasible to change permissions through the Roles Modifier every day, or to quickly react to changes.
Within our Permissions Layer, the managed account grants a broad approval through the Roles Modifier, which empowers a second permissions contract—the Sub-roles Modifier—to delegate within those approvals to other sub-accounts. That delegation is controlled by the manager account, allowing for rapid configuration of permissions for other managers or automated agents to share the workload. The delegate accounts cannot collectively exceed the original permissions, but can benefit from regular and rapid adjustments to suit their changing needs.
It’s just one example of how our Permissions Layer tailors the experience of onchain asset management to save time and costs, expedite time-critical security operations, and share the benefit of our experience more broadly.
Tooling & The DeFi Kit
It’s not all just about the onchain experience, either.
In many ways, the offchain experience—mapping out permissions & roles, or preparing copious input data—can be the bigger pain point. The complexity of these permissions processes can be a key vector for human error, or even offchain exploits. And having each organisation reinvent its own permissions wheel is hopelessly inefficient.
That’s why we built the kpk DeFi Kit—a software development kit that standardises the process of building and managing permissions into just a few human-readable fields of data entry. The kit automatically generates payloads to create Roles Modifiers and Sub-roles Modifiers, and interact with them to add or manage permissions. It means you don’t have to interact directly onchain, or even understand how the underlying smart contracts work; you just use DeFi Kit.
DeFi Kit also empowers clean and simple user interfaces to abstract away complexity from the end user. For kpk’s partners, we have developed a sophisticated all-in-one platform for onchain asset management, with permissions at its core. Alternatively—as DeFi Kit is an open-source codebase—external users are free to put these tools to use in their own way without our input.
With the tools from DeFi Kit, our kpk Permissions Layer empowers all different kinds of treasury teams—from DAOs to endowments, foundations and traditional institutions—to better safeguard against malicious calldata when preparing and executing onchain transactions.
Unstacked
The kpk Permissions Layer is a foundational body of tooling and technologies, which together provide a complete solution to malicious calldata attack by eliminating all single points of failure. Where effective permissions management may be difficult and even risky to implement, we aim to simplify and secure the process with our cutting-edge technology. As the base of our non-custodial stack, permissions power every managed transaction that kpk presides over, on behalf of the industry’s leading treasuries.
kpk’s technology seeks to streamline onchain asset management at the forefront of our industry, through innovative smart-contract designs, like our Sub-roles Modifier, and simplified offchain services, like DeFi Kit. We provide a comprehensive solution that prioritises security and the self-custody of our users beyond all else.