In blockchain ecosystems, the need for a flexible and secure solution to store and access key material is paramount. One such innovative solution that addresses these needs is Lock-Keeper, a decentralized platform designed to manage digital asset custody with sophisticated access control mechanisms. At the heart of Lock-Keeper lies the concept of policies — rule-based constructs that define who may access blockchain wallets, under what conditions and for specific intended purposes.
In this post, we’ll dive into the concept of policies within the Lock-Keeper system, exploring how they work, and how they protect access to wallets within the Lock-Keeper ecosystem.
What Are Policies in Lock-Keeper?
Lock-Keeper policies are rules that determine how and when wallets may be accessed. They are designed to provide fine-grained control over who must approve the use of a wallet, under which conditions, and how the wallet may be used. Uses against a wallet include signing, exporting, or deleting.
At a high level, policies consist of a scope, which determines which policies apply to what wallet, and a list of authorizing entities that must approve the operation. For clarity, a wallet within Lock-Keeper is logically represented by a single key pair which can only be accessed through a key ID.
For example, a policy may say for all standard ethereum transactions with a transaction amount over 10000 wei, compliance and the CFO must approve, along with one of three optional entities (account manager, wallet owner, and CIO for example).
Multiple policies may apply to a wallet, and in that case, if any policies fail to be satisfied, the operation is denied.
Finally, Lock-Keeper employs a “deny by default” approach, meaning that permission must be granted before a wallet can be used. Meaning, if a newly created wallet does not have any policies in scope, then all operations on that wallet will be rejected.
Define a policy
Lock-Keeper administrators with the PolicyAdmin role may define new policies. Policies must also be signed by a Policy Approver authorizing entity before submission to Lock-Keeper. The Lock-Keeper Policy Builder assists with this task, and will be covered in a future blog post.
The primary elements of a policy are scope and approvers. Scope determines if a policy applies to an operation. Scope definitions include:
- Domain – Defines jurisdiction over a wallet. All wallets belong to a domain.
- Wallet ID – ID that identifies a specific wallet (a Lock-Keeper key pair).
- Transaction Types and Message Types – Supported types are standard Ethereum, EIP-1559, EIP-712, and ERC2771.
- Amount – Amount of transaction in wei.
- Usage – Sign, export, delete, or restore.
Scopes that are not defined mean that the policy applies to all types for that scope. For example, if a transaction type is not defined, the policy applies to all transaction types.
Approvers are the authorizing entities who approve operations. Lock-Keeper supports the concept of required and optional approvers. All authorizing entities specified as required must approve the operation. For the optional authorizing entities, the minimum required number must be met. For example, five optional authorizing entities can be specified, with a minimum of three required. Once the three have been obtained, the operation may be completed. Note that both the required and optional requirements must be satisfied.
Policy Examples
This section provides some real-life use cases of how policies may be defined and applied.
Transfer Policy
For all domains and wallets, require the CFO to approve any purchases. The CFO could verify the purchase is within budget.
Compliance Policy
A compliance entity must approve all cryptocurrency transactions. The compliance entity would verify that the destination address adhered to all Anti-money laundering requirements, and is not on a block list, such as Office of Foreign Asset Control (OFAC).
High Value Policy
For all domains and wallets, when signing a standard ethereum transaction with a value over 1000000000000000000 wei (1 eTH), compliance and the CFO must approve the transaction, and either the domain owner or account manager.
Shared Custody Policy
For a specific wallet, when signing, exporting, or deleting, the owner of the wallet and a designated co-signer must both approve the operation.
Meta transaction Policy
For all wallets in the Gasless Transaction domain, when signing a metatransaction (ERC2771), accounting must approve the transaction.
Key Export Policy
When exporting or deleting a wallet from the system, the CFO and wallet owner must approve the operation, and either compliance or the account manager.
Keys are split into three “shards” and stored on separate key servers, providing robust security through geographic redundancy. This ensures that precious keys are never exposed.
Conclusion
Policies in the Lock-Keeper system provide customers with powerful tools to enforce custom rules and conditions for wallet access, ensuring that wallets are only used or modified when certain criteria are met. With a wide range of policy scopes — from transaction types to value — Lock-Keeper offers the flexibility needed to manage assets securely, efficiently, and in compliance with governance or business requirements.
By leveraging policies, customers can create more secure, flexible, and autonomous systems for decentralized asset custody, unlocking new possibilities for both traditional financial institutions and the emerging world of decentralized finance.