RADIX WikiRADIX Wiki

Overview

On Radix, every account is a smart account – a programmable component on the ledger with configurable access rules, deposit preferences, and recovery mechanisms. This is not an add-on feature; it's the default account type.

Each smart account can:

  • Control access – Define which keys or badges can withdraw, deposit, or modify the account via access rules
  • Filter deposits – Accept or reject specific resource types (spam token prevention)
  • Multi-factor security – Combine multiple keys via the MFA Security Shield
  • Social recovery – Designate trusted contacts who can help recover access

Compare to Ethereum's EOA (externally owned account), which is just a private key with no on-chain logic. Ethereum's "smart accounts" (ERC-4337) are a retrofitted workaround; on Radix, they're native.

Who Can Call What

An account is a component of the native Account blueprint, and its authorisation template says which of its methods the owner reserves and which anyone may call. The owner holds withdraw, lock_fee, create_proof_of_amount, burn, the deposit-rule setters, and – against expectation – deposit and deposit_batch.

Four methods are public, and they are the four a stranger sending you tokens actually uses: try_deposit_or_refund, try_deposit_or_abort, and the batch form of each. The difference between the pair is what happens when the account declines: a refund returns the resources to the sender and lets the transaction carry on, an abort fails the transaction outright. Making the unconditional deposit owner-only is what gives the deposit rules below any force – a sender cannot route around them, because the method that ignores them is not one they are allowed to call.

Deposit Rules

An account carries one default and a list of exceptions. The default is Accept, Reject, or AllowExisting, which takes a resource only if the account already holds some of it. Each exception sets a resource to Allowed or Disallowed, and which list is consulted follows from the default: under Accept the deny list applies, under Reject the allow list applies, and under AllowExisting both do.

AllowExisting is the setting that answers airdrop spam. An account holding XRD and two tokens it chose keeps receiving all three without maintaining any list, and nothing else reaches it. Separately, an account can name authorized depositors – badges whose holder may deposit regardless of the rules – which is how an exchange or a payroll contract keeps paying an account that otherwise rejects unknown resources.

From a Key to a Badge

An account created by a wallet is not written to the ledger first. Its address is derived from the hash of a public key – the entity types are GlobalPreallocatedEd25519Account and GlobalPreallocatedSecp256k1Account – so the address exists, and can receive tokens, before any transaction creates the component. The engine instantiates it on first use, with its owner role set to the signature of that key.

securify is the one-way door out of that arrangement. Calling it mints a non-fungible named "Account Owner Badge", whose local id is the account’s own address bytes, hands the badge to the caller, sets the account’s owner role to whoever holds it, and sets the securify role itself to DenyAll so the call cannot be made a second time. Control has moved from a key to a transferable badge, and a badge is a resource like any other: it can sit in a vault, be held by a multi-signature component, or be governed by an access controller. That is the mechanism behind the MFA Security Shield and behind social recovery, and neither needed a change to the account blueprint to become possible.

HydrateLast updated Sep 21, 2026v2.0.09 revisionsVerified Sep 21, 2026