Kadena Account Concepts

Understanding how Kadena accounts work is essential for using eckoWALLET effectively. This guide explains the unique aspects of Kadena's account model.

Overview

Unlike many blockchains where your address IS your public key, Kadena separates the concepts of account names and keys. This provides flexibility but requires understanding.

Key Concepts

Account Name vs Public Key

Account Name: Your unique identifier on the blockchain

Example: `k:5a2afbc631fc209296f5b1b9bfd3956048e3

bc40ca3cb62afac329c944be08f5f47`

This is what others send funds to
Stored on-chain

Public Key: Your cryptographic public key

Example: 5a2afbc631fc209296f5b1b9bfd3956048e3bc40ca3cb62afac329c944be08f5f47
Used to verify signatures
Part of your account's keyset

Private Key: Your secret key (never share!)

Used to sign transactions
Proves ownership
Encrypted in eckoWALLET

Kadena Account Structure

Every Kadena account consists of three components:

1. Account Name

The unique identifier for your account.

k: Accounts (Most Common):

k:5a2afbc631fc209296f5b1b9bfd3956048e3bc40ca3cb62afac329c944be08f5f47

Format: k:{publicKey}

The "k:" prefix indicates a single-key account
Followed by your 64-character public key
Most eckoWALLET users have k: accounts

Other Account Types:

w: accounts: WebAuthn-based (SpireKey)
c: accounts: Custom accounts with specific names
Named accounts: Like alice.kadena or company-treasury

2. Keys (Keyset)

A set of public keys that control the account.

Single-Key Account (k:):

{
  keys: ["5a2afbc631fc209296f5b1b9bfd3956048e3bc40ca3cb62afac329c944be08f5f47"],
  pred: "keys-all"
}

Multi-Key Account:

{
  keys: [
    "5a2afbc631fc209296f5b1b9bfd3956048e3bc40ca3cb62afac329c944be08f5f47",
    "8d5f3c2a1b9e7f4d6c3a2b1e8f7d6c5b4a3e2d1c9f8e7d6c5b4a3d2e1f8c7b6a5"
  ],
  pred: "keys-all"
}

3. Predicate

Determines how many signatures are needed.

Predicate Options:

keys-all: Requires ALL keys to sign

{
  keys: ["key1", "key2", "key3"],
  pred: "keys-all"
}
// Requires all 3 keys to sign

keys-any: Requires ANY ONE key to sign

{
  keys: ["key1", "key2"],
  pred: "keys-any"
}
// Only 1 of the 2 keys needed

keys-2: Requires AT LEAST 2 keys to sign

{
  keys: ["key1", "key2", "key3"],
  pred: "keys-2"
}
// Need at least 2 of the 3 keys

Custom: Custom Pact functions for complex logic

(defun custom-guard (count:integer)
  (>= count 2))

Multi-Chain Architecture

Kadena has 20 independent chains (0-19), and this affects how accounts work.

Same Account, Different Chains

Your account name (e.g., k:5a2afbc...) can exist on multiple chains:

Chain 0:

Account: k:5a2afbc...
Balance: 10 KDA

Chain 1:

Account: k:5a2afbc...
Balance: 50 KDA

Chain 2:

Account: k:5a2afbc...
Balance: 0 KDA (doesn't exist yet)

Key Points:

Same account name on different chains
Separate balances on each chain
Account must be "created" on each chain (happens automatically when receiving funds)
Separate transaction history per chain

Why Multiple Chains?

Scalability: More throughput across chains
Lower Fees: Less congestion per chain
Parallel Processing: Transactions on different chains don't wait for each other

Cross-Chain Transfers

You can transfer KDA between chains:

Example: Transfer 10 KDA from Chain 1 to Chain 8

Source: k:5a2afbc... on Chain 1
Destination: k:5a2afbc... on Chain 8

The same account receives funds on a different chain.

See Cross-Chain Transfers for details.

Account Creation

k: Accounts

Created automatically when you:

Create wallet in eckoWALLET
Generate a new account
First time receiving funds on a chain

Creation Process:

(coin.create-account
  "k:5a2afbc..."
  (read-keyset "ks"))

Custom Named Accounts

Must be created explicitly:

(coin.create-account
  "alice.kadena"
  (read-keyset "alice-keyset"))

Requires:

Defining a keyset
Calling create-account
Paying gas fees

Keysets and Guards

Keyset

Defines who can access an account.

Structure:

{
  "keys": ["pubkey1", "pubkey2"],
  "pred": "keys-all"
}

Stored in:

Transaction metadata
Smart contract code
On-chain definitions

Guard

A more general concept that includes keysets and other authorization mechanisms.

Types of Guards:

Keyset Guard: Standard key-based
Pact Guard: Requires specific Pact code execution
Capability Guard: Based on capabilities
Module Guard: Controlled by module logic

Capabilities

Capabilities are fine-grained permissions for operations.

Capability Structure

{
  name: "coin.TRANSFER",
  args: ["k:sender...", "k:receiver...", 1.0]
}

Common Capabilities

coin.GAS:

{
  name: "coin.GAS",
  args: []
}

Permission to pay gas fees.

coin.TRANSFER:

{
  name: "coin.TRANSFER",
  args: ["k:from-account", "k:to-account", amount]
}

Permission to transfer specific amount from specific account.

coin.TRANSFER_XCHAIN:

{
  name: "coin.TRANSFER_XCHAIN",
  args: ["k:from-account", "k:to-account", amount, "target-chain-id"]
}

Permission for cross-chain transfer.

Why Capabilities?

Capabilities provide fine-grained control:

Specify exact actions allowed
Prevent over-authorization
Clear audit trail

Example: Instead of giving blanket permission to a dApp, you grant specific capability to transfer specific amount to specific recipient.

Principal Accounts

A special account type that uniquely identifies a keyset.

Format: k:{publicKey} is actually a principal account

Benefits:

Unique across all chains
Deterministic from keyset
No separate creation needed

Account Ownership and Security

Who Controls Your Account?

Your account is controlled by:

The keyset defined for the account
Whoever has the private keys in that keyset

Security Model

For k: accounts:

Single private key controls everything
Lose private key = lose account access
eckoWALLET encrypts with your password

For multi-sig accounts:

Multiple keys required
More secure for organizations
Requires coordination

Recovery Phrase

Your eckoWALLET recovery phrase (12 words):

Generates your private keys deterministically
Same phrase = same keys = same accounts
Keep it secure and backed up

Common Account Patterns

Personal Use

Single Account on Multiple Chains:

k:5a2afbc... on Chain 1 (main)
k:5a2afbc... on Chain 8 (DeFi)
k:5a2afbc... on Chain 13 (NFTs)

Business/Treasury

Multi-Signature Account:

Account: company-treasury
Keys: [ceo-key, cfo-key, cto-key]
Pred: keys-2

Requires 2 of 3 executives to sign.

DeFi/Smart Contracts

Module-Controlled Accounts:

Account: liquidity-pool-xyz
Guard: (module-guard "dex-module")

Controlled by smart contract logic.

Account vs Wallet

Understanding the distinction:

Wallet (eckoWALLET):

Software interface
Manages private keys
Signs transactions
One wallet can manage multiple accounts

Account:

On-chain identifier
Holds balances
Has transaction history
Can be accessed from any wallet with the private key

Example:

Your eckoWALLET (wallet) manages 3 accounts
Each account exists on blockchain
Same accounts can be accessed from different devices using recovery phrase

Practical Implications

Sending Funds

What you need to know:

Recipient's account name (k:...)
Which chain to send on
Both sender and receiver on same chain (or use cross-chain)

Example:

Send to: k:recipient-pubkey
Chain: 1
Amount: 10 KDA

Receiving Funds

What you share:

Your account name (k:...)
Which chain you want to receive on
Network (mainnet vs testnet)

Checking Balance

Must check each chain:

Chain 0: 10 KDA
Chain 1: 50 KDA
Chain 2: 0 KDA
...
Total: 60 KDA across all chains

Advanced Topics

Account Rotation

Change keys controlling an account:

(coin.rotate "k:5a2afbc..." (read-keyset "new-keyset"))

Use case: Upgrade from single-key to multi-sig

Account Guards

More complex authorization:

(defun custom-guard ()
  (and
    (>= (at 'balance (coin.details "k:...")) 100.0)
    (at 'approved (read approvals "tx-id"))))

Namespaced Accounts

Accounts within modules:

free.my-dapp.user-account

Controlled by module logic.

Comparison with Other Blockchains

Ethereum

Ethereum:

Address = Public Key Hash
No separation of account and keys
Changing keys = new account

Kadena:

Account name separate from keys
Can rotate keys on same account
More flexible

Bitcoin

Bitcoin:

UTXO model (no accounts)
Address per transaction