One of the headline new features of the Babylon upgrade to the Radix Network is the Smart Account – a radically better way of defining what a crypto account is. Part of what makes Smart Accounts so revolutionary was presented at RadFi, but maybe you’ve been wondering, “how can there really be no requirement of a seed phrase?” or “what’s this no-airdrop mode I’ve heard about?” or “what can these smart accounts actually do on Babylon?”
Read on, and all will be answered!
Smart Account Basics
The Smart Account concept starts from an essential pillar of Radix’s design: assets should be first-class objects. Tokens on Radix aren’t just balances in a bunch of ERC-20 smart contracts — they are standard features of the network with behavior enforced by the Radix Engine.
Because assets are so fundamental to the Radix platform, the accounts that hold them have to be just as fundamental. Radix accounts can’t just be addresses assigned to balance entries in token smart contracts, as on other blockchains. Radix accounts must be actual containers for assets that the account’s owner controls. (And doesn’t that also make a whole lot more intuitive sense?)
Fortunately, Radix has just the thing: components. Components are Radix’s form of “smart contract”, but because assets are a fundamental network feature on Radix, components can hold not just data (as on other networks) but assets. The logic of a component smart contract can directly control and manipulate the assets they hold in powerful and intuitive ways.
Putting it together, accounts on Radix are actually a built-in, “native” component designed expressly for the purpose of intelligent storage and management of assets. Because they are components with program logic, they can include all sorts of features to make them flexible, useful, and standardized in behavior – that’s why they’re called Smart Accounts. Among other benefits, the Smart Account component design can take advantage of Radix’s powerful built-in authentication system to define who can interact with the assets they hold.
Because Smart Accounts take advantage of all of this built-in network capability, they are not – unlike Ethereum’s ERC-4337 – an extra layer of functionality tacked on top of an existing system, creating complexity and compatibility challenges. Smart Accounts are simple, secure, and work frictionlessly with other components, dApps, and the Radix Wallet automatically.
Now let’s get into what Smart Accounts can actually do, and how they work, right from the start on Babylon.
Eliminating the Single Seed Phrase
Maybe the most exciting feature of Smart Accounts is that they need not be controlled by a single seed phrase. This means that users are no longer required to write down a long list of words and guard them in fear of losing their money.
There is no trickery here – no hidden seed phrase buried beneath multi-factor features, and no centralized system secretly making it work. How is this possible?
The key (pun intended) is Radix’s built-in authentication system using badges and proofs. Remember that assets are first-class objects on the Radix network. A badge is just an asset (a token or NFT) that is used primarily for authentication – kind of like an access card or membership card in your wallet.
The way badge assets are used for authentication is that Radix allows the holder of a particular badge to create a proof within a transaction that they are its owner. That proof is a temporary object that only exists during the transaction and that component logic can see. When components define their own authentication rules, they can require proofs of specific badges to permit various actions with that component.
The result is that every component – and therefore every Smart Account – is like a house where the doors can have locks that are only opened by certain keys.
You might see where this is going. Because Smart Accounts can specify the “keys” (badge proofs) to its “locks” (authentication rules), the ability to withdraw assets from an account – or do anything else with the account – doesn’t have to be bound forever to a single private key or seed phrase. The owner can change the locks on the doors.
This badge-based auth is very flexible, especially when including one more feature of Radix: virtual badges. Virtual badges provide a link between traditional transaction signatures and Radix’s asset-oriented, badge-based authentication system. It works like this: Each transaction submitted to Radix will have one or more signatures applied to it. When the transaction is run, Radix automatically translates each of those signatures into proofs of virtual badges that are automatically included in that transaction. The virtual badges vanish at the end of the transaction, but the proofs can be included in the auth rules of Smart Accounts – just like regular non-virtual badge assets. This allows Smart Accounts to require a given signature as the “key” to its “locks”.
By default, when a Smart Account is created, its auth rules are automatically configured to be controlled by a single virtual badge: typically a signature from a private key derived from seed phrase. This can be done totally offline, just like on any other blockchain, with a keypair automatically corresponding to a Smart Account address. This is a convenient way to quickly create an account the user controls without any more special configuration.
But the story doesn’t end there. Later, the owner of the account can tell the Smart Account to change its auth rules to look for a different badge (or badges) instead of the one that was originally set. That might be a different virtual badge derived from a different private key, or it might be any standard “real” badge asset. Once that change is made, the original private key and seed phrase become completely obsolete – they literally no longer exist in the system.
This is a revolutionary difference from other crypto networks. Typically, a given account is forever controlled by a single, unchanging private key (ie. seed phrase). On Radix, a certain seed phrase may have been set as the first key to the locks on the house, but after changing the auth rule locks, that key (and its seed phrase) can be thrown away in favor of another.
Multi-Factor Control
This still doesn’t quite explain how Smart Accounts can provide powerful, on-ledger multi-factor control however. To do this, Radix provides one more important tool: the Access Controller component. Like Smart Accounts, the Access Controller is a built-in native component with special features. An Access Controller is intended to be paired with a Smart Account to provide more complex authentication rules – in short, multi-factor features.
This pairing to an Access Controller is enabled by another feature of the Smart Account: its owner can ask it to create a special, real (non-virtual) owner badge asset, which then has control of the Smart Account. That owner badge is then deposited into the Access Controller. Now the Access Controller’s own multi-factor rules and logic must be satisfied before it will produce a proof of the Smart Account’s owner badge to withdraw or do other things with the account in a transaction.
To go back to the house/lock/key metaphor, an Access Controller is like a professional security guard that holds the key to your Smart Account’s doors. If you can satisfy the security guard’s rules of “who may enter the house”, it will unlock the door for you (by producing a proof of the Smart Account’s badge) and let you do what you need to do.
What kind of rules can we give an Access Controller security guard? In short, just about anything using all sorts of combinations of badges. Remember how any signature produces a virtual badge? Well, there are lots of ways of generating signatures, giving us lots of interesting options to combine. For example, we can build rules including:
- A key protected by biometrics on a mobile phone
- A hardware device like a Yubikey, Arculus card, or hardware wallet
- The answers to a set of personal questions
- A seed phrase you wrote on a piece of paper (if that’s really what you want!)
Each of these things (and many more) can be used as “factors” in a multi-factor ruleset in the Access Controller. Perhaps you want to be able to quickly withdraw assets from one account with just your mobile phone. Maybe another account is holding enough value that you want to require both your phone and a secondary hardware device. Maybe you even want to require two-out-of-three factors. The Access Controller makes it possible to create all of these rules for who can access a Smart Account in a transaction, to withdraw tokens and more.
But it’s not only about who can access the account – we also want to give our security guard rules for changing the rules in case I lose a factor…
Multi-Factor Recovery, Including Social Recovery
The combination of Smart Account and Access Controller allows more than just setting the rules for who can do things like withdraw assets from an account. You don’t want your security guard to have a single set of multi-factor rules of access forever. What happens if you lose a critical factor? Now not only can you not convince the security guard to open the door for you, you can’t convince him to change the rules to fix the situation.
For example, perhaps you set a Smart Account (via its Access Controller) to be controlled by a key held on your mobile phone, plus a Yubikey. You need them both to withdraw any tokens (multi-sig control!). That’s very convenient and secure, but what if you lose your phone, or just buy a new one? How do you get access to your account again?
This missing piece of the picture is that we want to be able to change the rules when needed, and use a different combination of factors to do it. That way, you can lose a factor or two and still have a way to recover access by changing the rules to use a new set of factors.
To support this, the Access Controller also includes multi-factor recovery features. Basically these are special multi-factor rules that define who can give the security guard new rules. It uses a “three role” system, where 2 out of 3 roles must agree in order to change the Access Controller’s rules.
Each “role” is a collection of one or more factors that must be provided to use that role’s vote. One role is the “primary” role that controls the account – just as described above. Two other roles, using different factors, can cast a second vote and also have other special powers in the recovery process.
The result is that if you lose your phone (which might be set as your “primary” role’s factor), you can use the factors of your other two roles (perhaps a hardware wallet device and a set of secret security questions) to allow you to change the “primary” to use a new key on your new phone.
Also, one of those two extra roles also lets you initiate a timed recovery. Basically this is your last resort option if you lost the factors for both of the other roles. In this case you can still get control of your account back – but you will have to wait a predefined amount of time to do so (during which you can safely cancel the recovery).
Radix’s badge-based auth system really shines on recovery. Because badges can be not just virtual but real on-ledger assets (like tokens or NFTs), one of your Smart Account’s recovery roles can be given to an actual badge token that you provide to a friend or trusted contact. Voila – Smart Accounts have “social recovery” where your friend can help you get access to your account again in a pinch.
Put together, this enables a recovery process that can feel very much like a familiar Web2 account recovery process, but totally decentralized. For example, getting a new phone might just be a matter of getting your friend to push a button in his wallet, and then you entering answers to some personal questions on your new phone. The three-role model allows the wallet to encourage and help set up typical, safe “something you have, something you are, something you know” security patterns – while also allowing power users to configure essentially whatever combination of rules and factors they wish.
Configuring and using Smart Accounts (and associated Access Controllers) will typically be done using the Radix Wallet, which will make this all easy to understand and guide users to set up good security patterns. While all of the on-ledger Smart Account and Access Controller features for multi-factor control and recovery are immediately available with Babylon, full UI-level support in the Radix Wallet (including various signing factors) is coming soon.
Third-Party Deposit Settings, Including No-Airdrop Mode
But wait, there’s more! The Smart Account system means that accounts can have extra functionality beyond basic withdrawals and deposits, and multi-factor control.
On most other blockchains, the concept of “send token” is implemented in the token smart contract (not as a network feature) – meaning the account owner has no control over what they do or don’t want to receive. Anybody can airdrop any token to any account they want. Sometimes you may want that, but not always. Shouldn’t the account owner have a say in what tokens they want to receive?
The Smart Account system makes this possible. On Radix, “sending tokens” means withdrawing from one account and depositing to somebody else’s. And “depositing” can have auth rules set in the Smart Account logic, just like for “withdrawing”.
In the Smart Account design, you, as the account owner, can always deposit whatever assets you like to your account. But third parties are given their own way of depositing to your account that operates kind of like a mailbox with rules set by the owner. Anybody can attempt to deposit an asset to your account, but if that deposit violates your rules, it instantly (within the transaction) bounces – return to sender!
You have a variety of options for setting the third-party deposit rules on each of your accounts (exposed through the Radix Wallet):
- You can set a default rule for whether you wish to accept all third-party deposits, none at all, or only third-party deposits of assets that the account has previously held (a.k.a. “no airdrop” mode).
- You can specify particular tokens that you’re happy to always receive or never want to receive – regardless of your default rule.
- You can specify that the holder of a particular badge is able to make deposits to your account freely, despite the other rules (a feature particularly useful for dApps that wish to request permission to make deposits).
Miscellaneous Bonus Features
To round out the picture, Smart Accounts (and Access Controllers) have a few other utilities to make them useful. Here’s a sampling:
One feature is locking. This is an added piece of Access Controller functionality to help address the problem of “my phone got stolen and I can’t immediately migrate to a new one”. One of the Access Controllers three “roles” has the specific power to “lock” and “unlock” the ability for tokens to be withdrawn from the Account (as well as produce proofs of assets). This means you (or potentially a trusted contact) can put your Account in safe mode until you have the ability to properly update your security settings to remove your stolen phone from the picture.
Another feature is fee payment. In most cases, users will pay the XRD fees for transactions they submit. To support this, the owner of a Smart Account can instruct it to pay those fees (or technically “lock” a maximum fee amount) for the transaction. The ability to do fee payment this way has a nice benefit not possible on other networks: the user can choose which account they want to pay fees from, transaction by transaction.
One last feature is producing proofs. As described above, Radix’s auth system is based on proving ownership of badge assets (without those assets ever leaving where they’re held). That applies not just to Smart Accounts and Access Controllers but dApp components as well. You might be using a dApp that requires a special user ID badge for access. The Smart Account lets you easily produce proof of any assets it holds – and the Radix Wallet will show you that this is happening, just like it shows you deposits and withdrawals.
That covers the basics of Smart Account features at Babylon launch (if you’re a developer and want to understand how your dApps can interact with accounts, see this tech talk post). But one of the wonderful benefits of Radix accounts being defined in a universal native component is that later protocol updates to the network can add more functionality. It is imagined that features such as permissioned “direct debiting” from accounts and similar features may be possible in the future – all without adding new complexity to the network, or disrupting interoperability.
