Understanding Accounts on Kadena: Features and Use Cases

Traditionally, blockchain accounts have been solely associated with a public key. Historically in the first few eras, their functionality (complexity) has been limited. However, there is potential to increase flexibility, enabling blockchain accounts to be more versatile. In an ideal world, not only could a single smart contract control an account, but multiple people might also share ownership.

Taking these considerations into account, we’ve developed more advanced account functionality on Kadena. There are five different account types, each built with a robust set of features. Whether you’re a retail user or part of a legacy institution, there is an account type tailored to your needs.

In what follows, we break down security features and functionalities that make Kadena's accounts unique.

Unique Key Concepts and Terms for Kadena Accounts

Before exploring the different account types, it’s important to understand some interrelated concepts:

Guards and Multisig (Native Multisig)

A guard is the only security layer that governs an account. It is implemented as a multisig mechanism where multiple keys can be associated with the account. When a smart contract expression is executed, a capability is brought into scope, and the transaction continues only if the appropriate key (or keys, in the case of multisig) within the guard signs for that capability. In other words, multisig is the guard and signing method, ensuring that the correct combination of keys has authorized the transaction.

This design is what Kadena calls native multisig, meaning that rather than deploying a separate smart contract to manage multisig functionality, it is integrated directly into the account’s guard.

Capabilities and Scoped Signers (Smart Wallet Features)

Capabilities are permissions or authorizations that are brought into scope during the execution of a transaction. Scoped signers are the mechanism by which these capabilities are confirmed — by requiring the corresponding key to sign off on the transaction. These features are especially important for implementing smart wallet functionalities. For instance, a smart wallet might enforce spending limits, where one capability controls overall access and other, more restrictive capabilities control high-value or small-value expenses.

In summary, while multisig via the guard defines who must sign off on operations (native multisig), capabilities are signed for via scoped signers and are used to introduce advanced smart wallet features that can, for example, limit spending to certain thresholds or categories.

Smart Wallets and Granular Guarding

Smart wallets on Kadena can define functions that limit spending based on distinct capabilities. Imagine an account table that supports multiple guards:

1. Overall account guard: Governs the entire account row.
2. Small expense guard: Governs low-value transactions.
3. Big expense guard: Governs high-value transactions.

Each operation (e.g., the defun bigSpend in a smart contract named SmartWallet) first verifies that the appropriate capability (e.g., the big expense guard) is in scope and that the required key signature is present. Only after successfully confirming this does it proceed to call the underlying function (such as wrapping the coin.transfer call) — which in turn requires the proper guard on the coin table to authorize the actual spending.

Different Account Types on Kadena

Kadena offers several different types of accounts. Note that named accounts—which are accounts allowing arbitrary human-readable names (longer than 3 characters)—should not be used in production because they open the door to account squatting by malicious users.

Here are the account types:

• name-accounts: Accounts with arbitrary names. Do not use these in production as they are vulnerable to squatting.
• k: for accounts governed by a keyset containing a single key and a keyset predicate of keys-all. A k: account ensures the binding between the public key and the account itself—what comes after the colon is the public key. This means the account can only be created when guarded by a keyset with a keys-all predicate and a single key, namely that public key (i.e. k:<publicKey>). This makes k: accounts perfect for individuals who require a secure account tied directly to their public key.
• w: for accounts governed by a guard configured with multiple keys (a native multisig implementation).
• u: for user-guarded accounts that connect to a specific smart contract, allowing custom contract logic to control behavior.
• c: for capability-guarded accounts that enforce capability-based access control within a smart contract.
• r: for reference-keyset accounts, which are governed by a keyset defined by a namespace.

k: for single keyset accounts

A k: account ensures the binding between the public key and the account. Since what comes after the colon is the public key, a k:account can only be created when it is guarded by a keyset with a keys-all predicate and a single key, namely that public key (i.e., k:<publicKey>). This setup makes k: account ideal for individuals who require a secure account tied directly to their public key.

w: for accounts with multiple keysets (native multisig)

w: accounts are designed with a guard that includes multiple keys. The associated predicate precisely defines the number of keys required to sign off on any function execution, supporting advanced use cases that require authorization from multiple parties.

u: for user-guarded accounts

u: accounts are directly connected to a specific smart contract. The smart contract’s functions control the account behavior, making it adaptable and reusable across the Kadena ecosystem.

c: for capability-guarded accounts

c: accounts enforce a capability-based access model where operations are permitted only if the relevant capabilities (brought into scope during the transaction) have been signed for. They are often used in conditional scenarios like escrows.

r: for reference-keyset accounts

r: accounts are governed by a keyset defined by a namespace.

Flexibility Meets Security

With advanced features like guards, scoped capabilities, and native multisig support, Kadena’s account designs offer robust security and flexibility. Kadena’s account system can handle your needs– whether you are about to send some $KDA to a friend, or you’re on the verge of creating an escrow with smart wallet features.

For a deeper technical dive into the concepts underpinning the Kadena ecosystem, please visit our docs site.