Exciting times are ahead for the Radix Network with the proposed Bottlenose protocol update, just released to the node runner community and targeted to be enacted on or around Monday, June 3rd.
Let’s examine what’s new and explain one of the key features—the AccountLocker blueprint—in simple terms.
Key Features of the Bottlenose Protocol Update
- AccountLocker Native Blueprint: A new blueprint designed to simplify handling account deposits.
- API Enhancements: New API for reading the component owner role from Scrypto.
- Protocol Parameters Exposure: New substates to reveal current protocol-related parameters.
- AccessController Improvements: Addition of a recovery fee vault, eliminating the need for third-party fee locking during recovery.
- Account and TransactionProcessor Enhancements: Various improvements to native blueprints.
- Radix Engine Enhancements: Various implementation improvements.
Understanding Lockers
One of the standout features of the Bottlenose update is the introduction of the AccountLocker blueprint. But what exactly is a Locker, and how does it benefit users?
Let’s break it down in simple terms.
What is an AccountLocker?
Think of it like an Amazon delivery locker. Any dApp can create an AccountLocker and place things in it for you to pick up later (if you want to).
Why Do We Need AccountLockers?
No Delivery Issues: Accounts on Radix can be configured to refuse unfamiliar tokens, which stops undesired deposits (like airdrops) from being accepted. However, sometimes, an application has a need to ensure delivery, regardless of account settings. For example, think of a cross-chain bridging application – the bridging operation needs a guaranteed way to get those tokens to the recipient on the Radix side and won’t be willing to hold on to them on their behalf. So, it creates an AccountLocker and routes all deliveries through it. If the receiving account is configured to accept deposits, then tokens get deposited directly. If not, then they sit in the Locker, waiting for the account’s owner to come claim them.
Easy Bookkeeping for dApps: Applications using AccountLockers don’t have to keep track of who they owe what; they can easily get tokens “off the books” and know that they will be available for their intended recipients.
No Spam for Account Owners: Remember, AccountLockers are associated with applications, not accounts! As an account owner, you don’t get spammed with knowledge of all the deposits that are available for you to claim. Applications that you choose to connect to can let you know that they have a deposit waiting for you in their associated Locker, and you can choose to claim them or let them sit.
Enhanced Airdrop Management
On Radix, accounts can block unwanted airdrops, giving users greater control. However, this doesn’t mean airdrops are dead on Radix. Here’s how Lockers make airdrops easy while respecting user preferences:
Each dApp can create its own Locker. If a dApp wants to conduct an airdrop, any tokens that couldn’t be directly deposited go into the Locker, keyed to each intended recipient.
Only the account owner can claim their airdrop from the dApp’s Locker. Developers can create a web frontend to let users claim their airdrops – just inform users to check that webpage.
You can still do your airdrop, and if it interests people who have airdrops disabled on their accounts, they can come and get it later.
Future Enhancements: Radix Wallet Support
In the future, the Radix Wallet will automatically discover any items waiting for you from dApps to which you have chosen to connect. And, of course, you’ll be able to opt out of continuing to pay attention to a particular dApp if you decide you’re not interested.
If you’d like a more detailed understanding of AccountLocker, check out the AccountLocker technical documentation.
