This month we have started allocating dev resources from the infra layer into the app layer, tackling the two poles of building on AO and the permaweb. Since the hb/acc manifesto inception in June 2025, and we have been working on building infrastructure around ao and HyperBEAM: meta-VM devices, the Load S3 temporary storage layer, and dev tooling.
Although we’ve shipped a lot on top of Load S3 storage (cloud.load.network, load s3 agent, share.ao, etc), we haven’t touched the direct app layer on ao network yet. And frankly, we believe it’s in our responsibility, despite our small size, as an ecosystem player to accelerate the app layer of ao, along the infra layer, and Load.
Work on the internal ao app layer begun when we started working on Atlas. Atlas was built first because we needed a tool to easily visualize $LOAD FairLaunch data for internal purposes. However the “why don't we generalize this tool?” question always come up when you build something internally useful. So we shipped atlas.decent.land and the API powering lunar.ar.io.
Today we are introducing treasury.ao after asking ourselves the very same “why don't we generalize this tool?” – something we need in the near future to securely custody AO network tokens.
Rationale
Beside wanting to tackle ao’s dapp layer, playing around with ao’s mainnet and looking to build a present solution hedging against out future-need to custody ao tokens in multisigs treasuries, we will be dedicating a fair portion of our dev resources to build the DeFi applayer on ao mainnet. More on this soon.
Back to Treasury, any mature DeFi ecosystem requires a multisig wallet. It’s something we faced when we started building the DeFi layer on Load’s Alphanet, a gnosis-safe deployment was necessary and requested by several early teams that built on the Alphanet. So with Treasury we are bringing our EVM DeFi experience into the ao ecosystem and trying to solve problems that will surely emerge as soon as the ao DeFi layer matures.
Introducing treasury.ao
treasury.ao is an open-source (unaudited, WIP) multisig wallet deployed on ao mainnet - the first of its kind on ao mainnet! treasury.ao, the web client, is powered by mux, the engine behind Treasury.
mux is the set of statically-typed ao processes that powers Treasury. We chose to write mux processes in Teal to have some level of type safety that lua lacks. The Teal processes get compiled to Lua before the deployment on ao. Soon we will drop a blog post detailing our ao processes developing architecture and designs.
In its V1 release, Treasury support the following functionalities:
- Custodying ao tokens
- Proposing, voting and executing ao token transfers proposals
- Multisig wallet settings, proposals to add new admins, remove admins, update the multisig’s meta data.
- Smooth UX of data visualization: detailed proposals data, pending-cancelled-executed proposals, detailed transfers data preview and history, etc.
Although Treasury V1 web app is strictly centered around ao tokens functionality, mux, the backend, can literally do any ao action now. Soon we will unlock an “Advanced” mode on the Treasury web app that allows the multisig admins to propose custom AO actions (custom calls to other processes).
An experimental treasury
First thing to do after creating your multisig treasury is to claim the worthless $BOB and $ALICE tokens from the faucet, and transferring the worthless tokens to your treasury to start experimenting with the core functionality - token transfers proposals
Creation flow:
Approval flow:
The state of Treasury/mux
At the time of writing this blog post, Treasury’s V1 is strictly for testing purposes. The multisig system is built on the latest HyperBEAM mainnet features (relies on the greenzone-authority feature), things that aren’t supported yet within the wider canonical ecosystem parts, such as the major tokens and processes ($AO, $PI, FLPs, etc), therefore sending any non-faucet token to your multisig will result to a permanent loss of assets.
V1 being is unaudited multisig wallet and we expected to find and patch several 🐛 while working on the upcoming releases.
Treasury depends on 2 critical points to be used in production and with tokens such as $AO:
- auditing a stable release
- the migration of major processes (such as $AO) to use HyperBEAM’s greenzone feature - a solution for authority fragmentation issues on AO network (legacy issue mostly).
So until we announce a stable audited release of Treasury, any release of the multisig web client and ao processes (mux) are experimental deployment on the ao mainnet network.
And this is aligned with our vision, we are hedging for the moment tokens like $AO migrate to the greenzone, by then treasury.ao should be ready for production usage.
What’s next
Our next few weeks will be focused on enhancing the security of mux processes, Treasury’s UI/UX smoothness and performance. A lot of debugging and edge cases tests.
Vision wise, we see an opportunity to make Treasury more than just multisig, but also a smart multisig (smart wallet), with features like social recovery, multisig-level allowance rate limit, address books, anti-spam txs filters, and the clarity of signatures, like seriously, who likes to sign txs with messages in base64 or hex formats? No blind signing! However, the smart wallet angle is something to work on after achieving a self-satisfying stable-test release of Treasury.
Conclusion
Treasury’s initial release today is the opening of a new parallel chapter for Decent Land Labs: DeFi app layer on ao mainnet. Soon we will be sharing more details about that, what we plan to build, and what we have built in stealth during January. The alignment between ao DeFi eco and Load’s L1 EVM eco, intercommunication and synergies.
TL;DR, the lab is double-down on building towards a greater unified Permaweb, tackling several angles at once. LFB!