This educational content comes to you with the support of the PoolTogether Growth Team. Visit PoolTogether.com to learn more and start your prize-savings journey.
You can also drop by the PoolTogether discord and join one the best communities in DeFi for friendly discussion, community-led events, and weekly community calls.
Hey friends 👋
When I first came across PoolTogether, the crypto prize-savings protocol, it was in version 3 (or v3 for short) and had recently launched on Polygon. At the time, there was a bit of a debate over the choice of Tether (USDT) to be the sole depositable asset on this new chain. Objectively speaking, Tether was, and is, the world’s popular stablecoin. However, it has remained controversial throughout the years due to its relatively opaque reserves, and some people prefer to avoid holding it altogether.
At that time, there was an alternative of sorts for those who wanted to avoid Tether but still make use of the protocol: users could deposit into one of several pools on Ethereum mainnet that included DAI, GUSD, COMP, and even PoolTogether’s governance token, POOL. There were also pools on Binance chain for BUSD and CAKE, and later on the Celo blockchain for their native stablecoins cUSD and cEUR. This gave users a decent amount of choice.
When v4 launched, the community opted to focus on changes to the way draws happen to help prevent whales from hoovering up all the prizes and make the protocol more fair and user-friendly. The management of additional pools was deemed by the community to be a distraction, and once again a single stablecoin pool was implemented; this time the token of choice was USDC.
Since the launch of v4 there have been numerous improvements, like adding additional USDC pools to Avalanche and Optimism; introducing the prize delegation feature; further tuning of the prize mechanisms and the introduction of large infrequent prizes.
But as all of this was happening, the PoolTogether community and the developers working on the protocol were dreaming up something big: the hyperstructure…
The concept of a hyperstructure comes from the mind of visionary architect Paolo Soleri who coined the term in his 1969 book Arcology: The City in the Image of Man (which can be read online for free here).
Arcology is a portmanteau of the words architecture and ecology. According to the website of Arcosanti, an arcology prototype city in central Arizona, designed by Soleri and under construction since 1970, the term can be defined in the following way:
Arcology is the fusion of architecture with ecology, a comprehensive urban perspective. In nature, as organisms evolve, they increase in complexity and become a more compact system. A city should similarly evolve, functioning as a living system.
To understand how this concept of physical infrastructure correlates to blockchain protocols, we need to turn to an essay written by Zora’s Jacob Horne from January 2022. In the piece, simply titled Hyperstructures, Horne argues that blockchains facilitate a new kind of digital hyperstructure in the form of smart-contract-based software protocols.
Like Soleri’s arcological creations, these blockchain protocols can be designed to operate in perpetuity without additional inputs required, just code executing by an unalterable set of rules. According to Horne, there is a set of criteria he uses to define what “can be considered a hyperstructure.” It must be:
“It is worth noting,” he adds, “that just because an application is protocol-based does not immediately mean it is a Hyperstructure.” It must meet these above criteria, each of which he further defines in the article.
Now, all of this is fascinating, but I’m pretty sure I can hear you asking already, “how does this relate to PoolTogether?”
When Brendan Asselstine, the Chief Technology Officer at PoolTogether Inc. read Jacob’s essay, he was clearly inspired. Roughly one year later, he referenced Jacob’s work in a post on the PoolTogether governance forum, announcing a vision for the future of the protocol as a hyperstructure. He began by outlining some key benefits of this approach as it would relate to PoolTogether:
Fundamentally, the hyperstructure is still a prize savings protocol. Users deposit assets, yield is awarded as prizes, and anyone can withdraw at any time.
However, it includes significant improvements:
The design supports any number of assets and yield sources
Prizes are adjusted automatically to ensure there are both large and plentiful prizes
The protocol runs autonomously without any kind of governance
New assets and yield sources can be added permissionlessly
The POOL token plays an integral part
After reading that, I, like many others in the community, was already hooked and ready to read onwards. What we found is a concept that removes any shortcomings from previous versions to create an incredibly versatile protocol.
Previous versions of PoolTogether have relied on depositing assets into carefully chosen yield sources; in v3, Compound Finance was the main source and in v4, it switched to Aave. This thoughtful oversight was a way to ensure relatively predictable returns with minimal risk to users.
This approach was limiting though, and many community members voiced their support for adding more pools in future versions, as there had been in v3. Anyone hoping for this will be happy to know that the new design not only allows for more pools to be created, it allows for infinite pools to be created. Furthermore, these pools can use any token, any yield source, and be created by anyone.
The only requirement is that these pools, hereafter referred to as vaults, must make use of the ERC-4626 standard. In case you’ve never heard of that— I hadn’t—here’s a little primer from the 4626 Alliance:
ERC-4626 is a tokenized vault standard. Vaults are smart contracts that take in token deposits and do something with those tokens to provide token rewards to the depositor.
Standardizing vault implementations makes it easier for applications, plugins, and tools to integrate with vaults.
Rather than building many custom adapters for each vault implementation, applications can easily build on top of any vault following the ERC-4626 standard.
A standard for tokenized vaults will lower the integration effort for yield-bearing vaults, while creating more consistent and robust implementation patterns.
Reading this, it makes sense why this standard is a key component of the hyperstructure’s design. But it’s only one part. The other key is the use of a common prize token.
Because vaults will have varying yields and total deposits of any given vault will vary as well, the most effective way to maximize returns for users is to combine all the yield into one token, and then distribute prizes in that token; the odds being proportionate to the value of the yield contributed.
Here’s a more detailed graphic which shows the complete flow from depositing any asset to winning the prize token (POOL), and, optionally, swapping for any other asset.
There are a few things that are unique to this design that we need to dig into deeper. First off, let’s look, let’s let Brendan explain what the Liquidator is:
The Liquidator contract liquidates yield for POOL. It’s a single-sided virtual AMM that treats yield as an instant virtual swap before each user swap. As yield accrues, this creates an arbitrage opportunity.
In his talk at PoolyCon he elaborated that this arbitrage will likely be done by bots.
Another thing this design makes possible is a system of claim-less prizes. While us long-time PoolTogether users have grown to love checking for prizes, it can also be easy to go some time without knowing you’ve won. There have been various workarounds like Discord and Telegram bots that can give you alerts when your wallet address shows up in the prize contract execution, but you still have to navigate to the dApp and claim your prize; not to mention pay gas fees.
In this new system, prizes will be dispensed automatically to the winners, and PoolTogether plans to design vaults that can automatically compound prizes back into deposit tokens, so that the user's chance of winning is automatically increased. This will be an opt-in feature, of course. And other automated strategies will also be possible.
The composability that comes from building this system around ERC-4626 is going to allow for a ton of flexibility. The goal is for PoolTogether to become a protocol in the truest sense of the word. No longer a dApp, but a piece of infrastructure that underlies other dApps or is built into wallets; a prize-savings public good.
There will be an official front end available, like there is for Uniswap, and it will allow for a high-quality user experience and features like vault curation (similar to Uniswap’s token lists). But this front end will be optional.
In Jacob Horne’s essay, he argues that for a protocol to be a hyperstructure, that, among other things, it must be valuable.
Owning a piece of PoolTogether means owning the POOL token. Currently, POOL holders govern the use of treasury funds and vote on protocol changes. But in a system which is by design governance-minimized, the latter of those incentives fades away.
This is why using POOL as the prize token is so meaningful. Since all yield is converted to POOL, there is increased market demand, making speculation and liquidity provision more valuable. As I already mentioned, there are arbitrage opportunities in the liquidation process, and POOL holders may also choose to provide liquidity on various AMMs.
Protocol-owned liquidity will also generate trading revenue, which could return to the DAO treasury, or, as proposed by Brendan in his PoolyCon keynote, swap fees could be burned, which would reduce supply and increase the value for all holders.
Regardless, of the exact details, this system provides a clearer value proposition for the POOL token by turning it into a true utility token. That sounds pretty bullish if you ask me. Don’t though because nothing in this post is financial advice.
PoolTogether v5, aka the hyperstructure, is currently live on the Ethereum Goerli testnet and members of the PoolTogether Guild that hold the following any of the following non-fungibles can unlock access to beta test it.
PoolTogether Contributor GitPOAP
Community Call 100, 101 or 102 POAP
For the rest of us, be patient while the developers continue their fine-tuning and expect a release in the coming months. Remember, the goal is to design something that can run forever, so it’s worth taking time to get the code just right.
And then, it’s onward and upward towards the hyperstructure
Until next time,
This content is funded by the PoolTogether Growth Team Coordinape circle. All opinions are my own.
If you enjoyed this blog post, consider collecting a copy. It's like tipping and receiving a unique digital collectible as a receipt.
And for the cypherpunks, I accept anonymous tips with Zcash to my shielded address: