Acki Nacki Blockchain - Account ID Specification

CAIP-10

For context, see the CAIP-10 specification.

Introduction

Acki Nacki uses a two-part account addressing scheme. Each account is identified by a DApp ID (256 bits) and an Account ID (256 bits), forming a 512-bit composite address called AccountRouting.

The DApp ID groups contracts into a logical application. All contracts within the same DApp ID share ONE (1) gas pool (defined in DappConfig) and can transact internally without gas costs. The Account ID uniquely identifies the contract within its DApp.

When a contract is deployed by an external message, its DApp ID equals its own Account ID (self-originating). When deployed by an internal message from another contract, it inherits the sender’s DApp ID.

Account Model

Acki Nacki uses an account-based model in which every account is itself a smart contract; there are no EVM-style externally owned accounts (EOAs). A private key is not an actor on its own — it can only sign external messages addressed to an already-deployed contract whose code chooses whether to accept the signature and execute. A “user wallet” on Acki Nacki is therefore a deployed contract (typically a multisig).

Peer-to-peer value transfers always flow contract-to-contract:

• Inside a DApp ID — internal messages are gasless: gas is drawn from the shared DappConfig pool via gosh.mintshell().
• From outside (external message) — the receiving contract pays gas from its own balance. A bare AccountID with no deployed contract is uninitialized: incoming messages either bounce or, when accompanied by a stateInit, deploy the contract at that address.
• Cross-DApp transfers — the native VMSHELL token is zeroed at the protocol level when crossing DApp boundaries; ECC tokens (e.g. SHELL) can cross.

A bare AccountID is therefore meaningful only as a destination address — it cannot originate a transaction until a contract has been deployed at it.

Specification

Semantics

An Acki Nacki account address consists of:

• DApp ID: 256-bit identifier (32 bytes, 64 hex chars)
• Account ID: 256-bit identifier (32 bytes, 64 hex chars)

Together they form an AccountRouting — the full address used for message routing and thread assignment in the Acki Nacki network.

Syntax

The CAIP-10 account address is the concatenation of the lowercase hex-encoded DApp ID and Account ID, separated by a period:

acknacki:<chain_id>:<dapp_id>.<account_id>

Where:

• <chain_id> is the CAIP-2 reference (e.g. 0 for mainnet)
• <dapp_id> is the 64-character lowercase hex DApp ID
• <account_id> is the 64-character lowercase hex Account ID

Hex encoding is lowercase and does not include the 0x prefix used in EVM-style addresses; both DApp ID and Account ID are exactly 64 hex characters with no separator.

For self-originating contracts (deployed via external message), dapp_id == account_id.

Validation regex for the account address portion:

[0-9a-f]{64}\.[0-9a-f]{64}

Total CAIP-10 validation:

acknacki:[-]?[0-9]{1,10}:[0-9a-f]{64}\.[0-9a-f]{64}

Resolution Mechanics

An account can be queried via the GraphQL API using only the Account ID portion (prefixed with 0: for legacy compatibility):

query {
  blockchain {
    account(address: "0:<account_id_hex>") {
      info {
        balance
      }
    }
  }
}

The DApp ID of a deployed contract can be determined from the deployment transaction: if deployed externally, dapp_id = account_id; if deployed internally, dapp_id is inherited from the sender.

Rationale

The two-part address reflects Acki Nacki’s unique DApp ID architecture. Unlike workchain-based addressing used in other chains, the DApp ID is a logical grouping mechanism that determines gas routing and thread assignment. Including both parts in the CAIP-10 address preserves the full routing information needed for cross-DApp operations.

The period separator (.) is used instead of colon (:) to avoid ambiguity with the CAIP-10 namespace:chain_id:address format.

Backwards Compatibility

This is the initial specification. No legacy identifiers exist.

Test Cases

# Self-originating contract on mainnet (dapp_id == account_id)
acknacki:0:03079cdd1f5c3044fb3f7993becb2f581ffc1e3d128db4afc411e7870af883c3.03079cdd1f5c3044fb3f7993becb2f581ffc1e3d128db4afc411e7870af883c3

# Child contract deployed within a DApp on mainnet
# (dapp_id = SwarmRoot address, account_id = child wallet address)
acknacki:0:afdfe5f15a73a966f38de23bd38436a6a0a0f02a4b81f53d30d6eab94b374610.5fcf27147706876b13be473280ca6fa3ce9e5babf3d288926d929ca37998a505

# Contract on shellnet
acknacki:1:03079cdd1f5c3044fb3f7993becb2f581ffc1e3d128db4afc411e7870af883c3.03079cdd1f5c3044fb3f7993becb2f581ffc1e3d128db4afc411e7870af883c3

Additional Considerations

The DApp ID system is fundamental to Acki Nacki’s gasless transaction model. Contracts within the same DApp ID share a gas pool via DappConfig, enabling internal transactions without explicit gas payment. Cross-DApp transfers of the native VMSHELL token are zeroed at the protocol level, while ECC tokens (SHELL) can cross DApp boundaries.

Future protocol upgrades may introduce additional addressing components (e.g., thread identifiers) that could extend this specification.

References

• Acki Nacki Documentation - Official documentation
• Acki Nacki Accounts - Account and DApp ID documentation
• DApp ID Guide - Full guide on DApp ID creation and fees
• CAIP-2 Profile - Acki Nacki chain identification

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Mitja Goroshevsky, "namespaces/acknacki-caip10: Acki Nacki Blockchain - Account ID Specification [DRAFT]," Chain Agnostic Namespaces, acknacki-caip10, April 2026 / . [Online serial]. Available: https://github.com/ChainAgnostic/namespaces/acknacki-caip10.md