Created using OpenAI’s DALLE2

State of Behodler Ecosystem

A time traveler’s guide to Behodler

In recent times, the progress reporting of Behodler has been fragmented across many different platforms, according to their relevance to the update. Github is the best place to view the actual coding in progress but a great deal of informal discussion on Telegram and more formal debates in Discord have taken place. Occasionally articles are published but not always through Medium. The monetary policy paper was of a technical nature and so was distributed as a markdown document.

Consequently to speak about what’s new in Behodler is a difficult topic. New from who’s perspective? Some in the community are completely up to date and need no refreshing while others feel as though the last thing to happen was the announcement of an audit with C4. So rather than outline what’s new since a nebulous sense of last time, we’ll give an overview of how things stand now and what more needs to be done by breaking the update into categories.

PyroTokens

The current version of PyroTokens that is live on the Behodler site as of today does not interact well with the UniswapV2 Router. They also cannot be used with UniswapV3 because fee-on-transfer tokens are not supported. Since Limbo is going to make use of Uniswap pairs that often will include PyroTokens, it would be unfortunate if users were thwarted from minting such pairs through a front end and had to resort to low level contract calls. This initiated a re-write of PyroTokens which gave the opportunity for many massive improvements over the status quo and birthed the concept of PyroTokens 3.

In short, the top highlights include:

• Fee exemptions on a per contract basis. This is useful where charging transfer fees would undermine a use case. For instance, if we ever needed to migrate from PyroV3 to a version 4, we could exempt the migration contract from charging transfer and redemption fees. Those of you who hold V2 will notice that when you migrate to V3, you will incur an unavoidable transfer fee. UniswapV3 compatibility is now possible for the same reason. This feature will allow, through governance, the exemption of Uniswap V3 pools. Projects such as ZooDAO which stake their user deposits in yield generating pools such as Yearn can now target PyroTokens as a source of deposit if the particular depositing contract is exempt from transfer fees. In other words, PyroTokens can now operate as a source of wholesale yield. The way a dapp like Zoo might go about this is to first have Zoo listed on Limbo. Once migrated to Behodler, PyroZoo would be created. Zoo could then submit certain contract addresses to PyroZoo so that whenever those contracts mint or redeem PyroZoo, they incur no fees. However, ordinary holders and traders of PyroZoo would continue to incur fees, pushing up the PyroZoo redeem rate.
• PyroLoans, endogenous yield generation of reserves. In prior versions of PyroTokens, the reserves were inert for security purposes. Growth of the redeem rate required trading fees from Behodler or from transfer and redemption fees. In version 3, the bookkeeping logic to lend out reserves has been added. This logic is open ended so that any number of creative solutions can be built on a per-PyroToken basis. In other words, PyroWeth can have a totally different loan system to PyroFlan.
• Natural rebase support for those who dislike redeem rates. With every PyroToken comes the option to have the token expressed as a rebase token. Here your PyroWeth would hold 1:1 redeem rate with Eth but as the redeem rate of PyroWeth rises, your balance of this 1:1 token would rise.
• PyroFlan booster. Since PyroFlan has Flan as a reserve, one obvious appeal of a continuous minting token like Flan is to establish a stream of perpetual Flan directly into the reserve so as to establish a base APY on PyroFlan. This contract has been written but won’t be released immediately.

The PyroToken UI is nearing completion but required some other aspects of the ecosystem to mature before it could be tested. Those parts, mentioned below, have been completed. The UI is the same as the existing one but will present holders of V2 pyroTokens a prompt to migrate to V3. There will also be some explanatory text on what PyroTokens are.

The current UI won’t support the rebase feature as the priority to release Limbo exceeds this.

Universal Deployment Script

Created using OpenAI’s DALLE2

A single deployment script for deploying the entire ecosystem from scratch has been created. It reads from a config file which is broken into sections (eg. Behodler, Lachesis, Morgoth, PyroTokens, BehodlerTokens etc), each containing the related addresses. For example, Behodler section has the addresses for LiquidityReceiver, Lachesis and Behodler. When addresses are left blank, the deployment script fills in the gaps by deploying the missing contracts. If the missing contract has dependencies on other contracts, the script hunts those down and deploys them first.

The script has been honed for a while to be fine grained configurable and tested quite thoroughly. Flan Genesis has been included as a section rather than as a separate ceremony. PyroTokens 3 is one of the sections as well.

It can now deploy an entire ecosystem in one step locally with snapshot capabilities so that UI devs can rapidly test features.

Audits

Limbo has undergone two audits. PyroTokens V3 were included in the second audit. The fixes for the audits are found in github as pull requests. A pending report outlining my thinking on each issue highlighted as well as discussion between the auditors and me will be released. The major issue highlighted was on the oracle system built in Limbo. It was inteded to be as simple as possible to avoid exploits through complexity but the auditors discovered that there was a tradeoff between griefing and vunerability. The less vulnerable to exploits, the easier Limbo would be to grief. In this case, a malicious entity with a high Eth balance could essentially freeze migrations indefinitely.

For a solution, I turned to Uniswap V2 TWAP. To be clear, TWAP is not an oracle but a source of “oracleness”. The developer still has to turn it into an oracle. There are downsides to using V2’s version that relate to real time availability of prices but that is not relevant to Behodler. We’re not using the oracle to know the precise per second price but to just to have a good estimate when it comes time to migrate.

Consequently, the Limbo UI can be significantly simplified and the end user need not know about oracles anymore which is a great victory for UX.

Proxies

We’ve been criticized for delaying release, often being likened to an obsessive artist who refuses to yield to the practicality of the market in order to achieve the perfect vision. This approach is not held in high esteem in business and especially in the realm of software where moving fast, breaking stuff, rapidly iterating and outsourcing has been a dominant ethos ever since Japan introduced LEAN engineering practices to the auto market. I want to make it clear that this image of the out of touch artist is not what’s driving the slow release process. Neither is the idea that I keep getting new ideas and never stop to release a minimal viable product accurate. Rather there are certain foundations of Behodler that have always been part of the vision, essential organs in a body that would otherwise die without them. These are the list of whats that have been discussed in Discord and elsewhere since Behodler became known. The appearance that I’ve suddenly come up with a new idea to chase is simply that I’ve discovered the best implementation of these whats. These new add-ons are manifestations of the how. We knew many of the whats long before we knew the hows. In the process of fleshing out the hows, bonus features naturally emerged that were not originally part of the picture.

A good example of this is the TokenProxyRegistry. Originally proxies were referred to as guardrail contracts. It was speculated and then strongly asserted that Behodler would need protective wrappers of tokens because all liquidity resides in one contract. The alternative is to have an intensive vetting process or to limit the set of allowable tokens to some small number of trusted tokens. Without proxies we would also need a relegation system when under-performing tokens drag the liquidity down — to kick the deadcoins off.

The proxy system turned out to be far more than initially thought but the power of the system can’t be underestimated. We now have 2 proxy contracts, one for Limbo and the other for Behodler. Any token can be listed on either platform without providing existential risk. This is huge! For the Behodler contract, it was discovered that a crashing price could be converted into impermanent gain as the burden of the crash would be transferred to arbitraging bots rather than liquidity providers. This is new in DeFi. What’s more, this mechanism can be plugged on top of any AMM which means Behodler is ground zero for a new way of protecting liquidity providers. In the future, you could crearte a pair on your favourite AMM and wrap it in cliffFace armour, protecting it from impermanent loss. The how turned out to be more marvelous than originally anticipated and any delay has been absolutely worth it. Proxies were also audited in both audits.

Market for Fate

Users staking EYE in LimboDAO would earn Fate, the governance token. But if Limbo has staking options for EYE such as EYE/SCX LP then it would undermine the desire to stake in LimboDAO. Consequently, only those expecting to profit from influence would generate Fate. Several mechanism for Fate conversion were considered and the thought process is highlighted in a previous update. Like PyroLoans, the best idea was to make it as open ended as securely possible. Through governance, contracts can be authorized to transfer Fate between users. This allows for special purpose dapps that allow prospective projects on Limbo to airdrop their tokens to holders of Fate. Imagine this: Project X wishes to list X token on Limbo. They don’t have enough EYE and do not have the capital to purchase EYE to either burn or stake in order to earn Fate. So instead, they perform an AMA to the Behodler community and promise to airdrop 10 X for every unit of Fate. They deposit one million X into a smartcontract with the exchange rate 10:1. Holders of fate can then send in their fate until either the X deposit is exhausted or some time period has passed. Once all the X is sold, a proposal is automatically put forward to list X on Limbo and 10 million Fate is added as a yes vote. Assuming this proposal passes, the Behodler community now holds X which can be deposited on Behodler to earn Flan.

The market for fate dapp hasn’t been written but the mechanism for adding such a contract has been added and audited in LimboDAO.

Behodler UI

The current UI is unaware of token proxies. The script will enable the UI dev to test changes against the new CliffFace proxies. As things stand, Flan will be protected by CliffFace. This will essentially add a price floor to Flan’s price. This is in addition to PyroFlan which acts as a bear market booster and of course Flan staking pools in Limbo.

Limbo Monetary Policy

As we near Limbo and especially during testnet, discussion on the best tokens to list will accelerate. Rewards that aren’t calculated carefully, especially on perpetual pools, could lead to Flan hyperinflation which would lead to the SCX price crashing. Limbo needs to be run in such a way that the following goals are met:

1. Flan does not hyperinflate but remains stable in value
2. While point 1 is achieved, SCX must not remain stable in price as this would lock the liquidity levels in Behodler.
3. SCX is drawn continuously into burning and holding to prevent accumulation of dangerous levels of free-radicle SCX.
4. Risk of SCX dumping during black swans is minimized.

To meet these goals, a theoretical white paper was written to explore the bounds of safety. Rather than make very specific goals which can lead a system to fragility, the policy paper simply outlines the boundaries within which it is safe for the community to play. If any of the variables approaches the boundaries, the community should immediately take sterilizing action.

Wiggum bots

Speaking of immediate action, before Limbo is popular, there may be long periods where the transactions in the dapps are not carefully monitored by the community. For instance, it’s conceivable that malicious proposals are lodged and voted on that appear benign. Bots will be deployed to notify and monitor the health of Limbo. There are a number of circuit breakers that anyone with sufficient EYE can trigger. The bots will likely trigger these as soon as dangerous conditions are detected.

Github Updates in Discord

A channel in Discord now highlights closed pull requests to give the community a glimpse into progress behind the scenes. We’ve also set up a live CCTV feed in CryptoCat’s living room without his knowing. Don’t tell him. He wouldn’t have read this much of the article.

“Cat in Limbo”

Steps remaining to public Limbo testnet

1. Finish PyroToken migration UI
2. Deploy PyroToken V3 to mainnet and switch the liquidity receiver on Behodler so that trading revenue flows to the new PyroTokens.
3. Make fixes to LimboUI to accommodate proxies and new oracle system
4. Basic LimboDAO UI (we’re looking into an autogen tool for now. Something like Remix but more tightly typed).

5. Testnet

Steps to mainnet from testnet

1. Adapt PyroFlan Booster contract to accommodate CliffFace
2. Execute Flan Genesis
3. Establish GUL strategy to synchronize Scarcity across layers. Here we want to figure out if it’s necessary to deploy L2s at the same time as Mainnet. We also need to figure out if each layer has its own DAO or if Mainnet LimboDAO controls all Limbos through governance relays.
4. Deploy to Mainnet and end Pooltogether.