Concept

Abstract account provides user with better experience and security than traditional Extenally Owned Accounts (EOA). Dchain natively supports this to offer dApps building on it to interact with users through compliant and non-custodial smart accounts.

Dchain Abstract Accounts use a modified version from the Vectis smart account framework. The core difference is that the Dchain abstractaccount module is used instead of the Vectis Factory Contract to create smart accounts and store relevant actors addresses for the framework.

The core features provided by the Dchain smart contracts for Abstract Accounts are as follows:

1. Proxy -  an smart contract that interacts with other modules / applications on-chain instead of a externally owned account, controlled by a Controller entity. This is where guardianships, plugins and other data is specified and stored.
2. The Controller entity - holds the desired authentication method (currently support Passkey) but other methods such as 2FA, ZKP of knowledge, other signature schemes can also be used.
3. Plugins - these are smart contracts that the controller can “install” on the Proxy. There are 3 main categories of Plugins
   1. Pre-Transaction checks: Conditions that must be satisfied given the controller input, such as spending limits
   2. Post-Transaction hooks: Conditions to be checked or executions to occur given the controller input, i.e. updating another dApp of the current balance
   3. Fine grain authorisations: and allow for extensible features such as session keys, autopay or auto-stake to interact and execute transactions from the Proxy address

Here are the key features:

1. Guardianship for key recovery

The user (owns the Controller entity) can appoint one or multiple of their trusted friends, family or other devices to be Guardians of their Proxy. Guardians can rotate the Controller entity in the Proxy and freeze the operations on the account.

From the applications point of view, the user is associated by their Proxy address, and in case of loss of their devices without Passkey backup, users can ask Guardians to replace the the Controller entity with a new one. If user has to leave their device in an unsafe place, they can freeze their account until further notice from the user.

2. Seedless Accounts and Seamless UX with browser extensions

Leveraging on Hardware Secure Modules in devices, companies such as Apple, Google and many password management applications such as 1Password are supporting Passkeys, which allows application to use Webauthn Credentials to create and Sign transactions. This removes the exposure of cryptographic material in plain text to be lost / duplicated.

An example of utilising this was built the Vectis PWA which is extension-less, which means users can access dApps via their mobile / desktop browsers all the same. To learn more visit our docs.

3. Ease of use - Automation by Authorisation

Plugins are smart contracts that the user can install by giving them access to execute certain functions, for example, direct debit. An example plugin is a wrapper around CronCat, which allows pre-set jobs to be executed on-chain at certain time(s).

AbstractAccountI Interface

The AbstractAccountI interface is the core mechanism for identifying and handling abstract accounts in the Dchain ecosystem. Any account type that implements this interface will be treated as an abstract account by the ante handler.

type AbstractAccountI interface {
    sdk.AccountI
    IsAbstractAccount() bool
}

The interface requires two key components:

1. sdk.AccountI: Standard Cosmos SDK account interface that provides methods like GetAddress(), GetPubKey(), GetAccountNumber(), and GetSequence().
2. IsAbstractAccount(): A boolean method that indicates whether this account should be treated as an abstract account in the transaction authentication flow.

Implementation in AbstractAccount

The AbstractAccount type natively implements this interface:

func (acc *AbstractAccount) IsAbstractAccount() bool {
    return true
}

For AbstractAccount types, the method always returns true, and the account uses a NilPubKey instead of a traditional public key for signature verification.

ContinuousVestingAccount as Abstract Account

Dchain extends the standard Cosmos SDK ContinuousVestingAccount in its dchain fork of cosmos-sdk to support abstract account functionality. This allows vesting accounts to function as smart contract-based abstract accounts.

Address-Based Detection

The ContinuousVestingAccount implements the AbstractAccountI interface with logic that determines whether it should be treated as an abstract account based on its address length:

func (cva ContinuousVestingAccount) IsAbstractAccount() bool {
    addr := cva.GetAddress()
    if addr == nil {
        return false
    }
    // Wasm contract addresses are 32 bytes, while regular SDK addresses are 20 bytes
    return len(addr) == 32
}

Key Points:

• 32-byte addresses: Identified as abstract accounts (wasm contract addresses)
• 20-byte addresses: Treated as regular SDK accounts (standard EOA addresses)

This design allows the same ContinuousVestingAccount type to function either as a traditional vesting account (with 20-byte address) or as an abstract account (with 32-byte wasm contract address), depending on the address length.

NilPubKey for Abstract Vesting Accounts

When a ContinuousVestingAccount has a 32-byte address (abstract account), it returns a NilPubKey instead of the base account's public key:

func (cva ContinuousVestingAccount) GetPubKey() cryptotypes.PubKey {
    if cva.IsAbstractAccount() {
        return NewNilPubKey(cva.GetAddress())
    }
    return cva.BaseVestingAccount.BaseAccount.GetPubKey()
}

This ensures consistent behavior with native AbstractAccount types and prevents panics during transaction signing and verification.

Use Cases

This dual-mode vesting account enables:

1. Token Distribution to Smart Accounts: Vesting schedules can be assigned to smart contract-based accounts (proxies)
2. Programmable Vesting: Combine time-locked vesting with smart account capabilities like guardianship, plugins, and advanced authentication
3. Seamless Integration: Existing vesting functionality works transparently with abstract account features

Note: While other account types like group accounts may also have 32-byte addresses, they are not expected to sign transactions directly, so the address length check is sufficient for distinguishing abstract accounts in practice.

Acknowledgements

Larry0x AbstractAccount module

• github
• youtube