Core Protocol

Wallet Runtime

The Runtime consolidates app execution, signature validation, and asset authority at the user address.

3 sectionsruntime

App execution

executeRuntimeApp(app, data) checks the app address, wallet-local enablement, and Registry status, then delegatecalls the app in the wallet's storage and balance context.

Any address can trigger executeRuntimeApp, but that does not grant wallet-owner authority. Owner-sensitive actions must use wallet self-signatures, ERC-1271 validation, or only-self constraints.

IAccountAppRuntime

interface IAccountAppRuntime {
  event AppEnabled(address indexed account, address indexed app);
  event AppDisabled(address indexed account, address indexed app);

  function executeRuntimeApp(address app, bytes calldata data)
    external payable returns (bytes memory result);
  function enableApp(address app) external;
  function disableApp(address app) external;
  function isAppEnabled(address app) external view returns (bool);
}

Storage and execution lock

The account core and every app use separate ERC-7201 namespaces.
A transient-storage execution lock rejects reentrancy and nested runtime execution.
Token and NFT pull contexts exist only during the current transaction.
Delegatecall failures bubble their original error data when available.

Account-level calls

executeBatch(calls) performs ordinary calls initiated by the wallet itself.
executeWithSig(call, deadline, signature) lets any submitter relay a wallet-signed call.
ExecuteWithSig uses an account-wide incrementing nonce and binds wallet, target, value, dataHash, and deadline.