YieldBlox Beta Roundup & Next Airdrop Steps

Published in
10 min readOct 22, 2021


The YieldBlox testnet beta just ended, and wow — what a ride! Our community was extremely involved throughout the beta. Altogether, they managed to farm over 472,000 YBX using a variety of strategies. The beta was also very insightful for our team: we plan to make a few changes to the smart contracts and a few bugs were fixed. Before we take a deep dive into the beta results, the end of the beta marks the end of the airdrop, so it’s time to announce a delay!

YBX Airdrop Update/Day-Zero Staking

As I’m sure you know, the airdrop was supposed to go out tomorrow. Unfortunately, due to some extenuating circumstances, we’ve had to modify airdrop distribution somewhat. YBX trustlines have ballooned to over 150,000 (almost half of which appeared in the last week), we ran some checks on the accounts, and we’re 99.99% sure ~130,000 are bots. So we’ll be disqualifying those accounts from the airdrop. This leaves us with ~20,000 accounts that we think belong to real people. Additionally, our discord membership has grown to over 16,000 accounts, despite banning over 10,000 accounts for appearing to be bots. While we think YieldBlox is amazing and are really proud of what we’re building, we’re not naive enough to believe that all 20,000 trustlines or all 16,000 discord accounts belong to people who are genuinely interested in using and growing YieldBlox. As we stated in the airdrop announcement article, the goals for the airdrop are to:

1. Get YBX into as many real ecosystem wallets as possible

2. Teach potential future users how to use YieldBlox

3. Grow the YieldBlox community

While the latter two of those goals have already been incredibly successful, the first goal is definitely in jeopardy. If we continue on course, it’s clear a large portion of airdropped tokens will end up in the hands of people who have no interest in YieldBlox or Stellar, which would be extremely unfortunate.

With this in mind, we are making the following changes to the airdrop:

Day-Zero Staking

When considering the YieldBlox tokenomics model, the most rational action for any individual who has long-term interest in the YieldBlox protocol is staking YBX tokens as soon as the protocol goes live. Doing so grants them yield from both token issuance and protocol fees; furthermore, they gain the ability to borrow against staked funds and participate in protocol governance. It’s a growth-positive action for both the individual and the protocol. For more information on staking, tokenomics, and growth positivity, see our last article.

We really couldn’t think of a good reason for users invested in the long-term success of the protocol to not stake on day zero. As a result, we’ll be offering all registered airdrop users the option to sign up for day-zero staking, which will issue their tokens directly into the staking smart contract. Users who elect for this choice will receive a 10x multiple on their airdrop entries. Note, the amount being airdropped remains the same, but users who opt into Day-Zero staking will boost their number of entries. Lastly, these YBX stakes will not be withdrawable with the early withdrawal function to prevent individuals from gaming the system (as we saw in the beta, you all are pretty crafty).


  • If a beta airdrop recipient farmed 1,000 YBX in the beta, that 1,000 will be considered 10,000 when we calculate the final payout.
  • A community airdrop recipient’s 1 entry will be considered 10 entries when we calculate the final payout.

Below, we’ve provided a quantitative analysis of the benefit of day-zero staking to help you evaluate the decision. Assumptions made in the model are based on user decisions during the beta. (Approximately 83% of YBX generated in the beta was staked, hence the 60% assumption in the model.) The model assumes a six-month staking period. As you can see, even factoring in token dilution, upon their stake unlock date, individuals who choose day-zero staking will end up with a 9x larger share of circulating YBX than they would have had on protocol launch had they not chosen day-zero staking.

To reiterate, the total YBX airdropped will remain the same, so the number of tokens distributed to individuals who choose not to do day-zero staking will be decreased. This decrease is in line with our desire to distribute the majority of airdropped tokens to individuals invested in the long-term success of YieldBlox. Finally, day-zero stakers will be able to choose the term they wish to stake for (3 months, 6 months, or 12 months). The sYBX multiples for the different periods will apply here. You can sign up for zero day staking manually by adding a trust line for one of the following assets. The YBX issuing account is the issuer for all of these assets.

  1. 3 month lockup day-0-stake asset code: Day0Stake3
  2. 6 month lockup day-0 stake asset code: Day0Stake6
  3. 12 month lockup day-0 stake asset code: Day0Stake12

For those unfamiliar with staking lockups I recommend reading the staking section of our docs

To sign up for day-zero staking, please visit our day-0-staking landing page linked below or manually add a trustline using this guide. Please note, you’re going to need to use the correct asset code. For those that do not want to manually add a trustline, we will add a signup tool on the landing page which will go live on Monday the 25th by 11:59 PM UTC and stay active until Thursday the 28th, 11:59PM UTC.

Please note — Bug Bounty payouts are not eligible for day-zero staking.

Changes to Distribution Periods

On a separate note, we’re a bit concerned about airdropping all tokens associated with the public and community airdrops simultaneously, as it would flood the market with tokens. Therefore, we will be staggering the airdrop into six payout periods to ease it into the market.

  • October 29th — Payout 1: 50% of Beta Airdrop (excluding Bug Bounties)
  • November 5th — Payout 2: 50% of Beta Airdrop (excluding Bug Bounties)
  • November 12th — Payout 3: 50% of Community Airdrop
  • November 19th — Payout 4: 50% of Community Airdrop
  • November 26th — Payout 5: 50% of Public Airdrop
  • December 3rd — Payout 6: 50% of Public Airdrop

Bug Bounties will be paid out to users on a rolling basis, starting on November 5th.

We’re sorry for making these changes so last-minute. But we think this will result in a much better outcome for all individuals legitimately interested in YieldBlox.

Beta Roundup

Now that we have airdrop news out of the way, let’s discuss the YieldBlox Beta! Quick precursor, if you didn’t have a chance to participate, we’ll be opening up the testnet version of the app to the public shortly, so make sure to check it out.

The YBX Harvest

The YBX beta had an airdrop tied-in where the amount of airdropped YBX participants received was tied to the amount of YBX they earned in the Beta. So it was essentially one big farming competition that gave us a great opportunity to test our protocol and architecture.

Farming Stats:

  • Maximum farmed by one person: 4,145 YBX
  • Top 20 farmers earned over 3,000 YBX each
  • The average amount of YBX farmed was 1,085
  • The minimum amount of YBX farmed was 0.000084
  • The median amount of YBX farmed was 897
  • 10 users were liquidated :(

Initial Beta State

Initially, all users were issued 2.4 BTC, 35 ETH, 85,500 EURT, and 100,000 USDC (testnet assets, we don’t have that kinda cash). We did not enable the use of XLM in the protocol, as it would have been possible for users to farm XLM from Friendbot and gain a much higher amount of assets than other users. Since YieldBlox regularly trades on the Stellar DEX through protocol operations, we also used a market-making bot to maintain large buy and sell walls for each protocol asset. This market-making bot tracked the price of the real-world assets represented by protocol assets to ensure realistic prices.

YBX Farming Strategies

We saw users employ a variety of strategies to farm YBX. The most basic one was lending and borrowing, as both lent and borrowed assets earn YBX token yield. On top of that, many users elected to employ circular lending. They lent all their assets, then borrowed, then lent the borrowed assets, and repeated until they reached very high leverage levels (and higher risk of liquidation). The highest leverage we saw was one user turning the roughly $500,000 we gave him into an effective $3.6 million lent!

One of the more unique aspects of YieldBlox is that each lending and borrowing asset has a different YBX token yield, which is set by a governance vote each week. To simulate this effect in the beta, we made the token yields for lending Bitcoin and Ethereum and borrowing USDC and EURT higher than the yield for other actions. Therefore, the optimal farming strategy was to lend BTC/ETH depending on which market was smaller and borrow USDC/EURT, again, depending on which market was smaller. Then swap the borrowed asset for more of the lent asset and rinse and repeat. A few users figured this out and traded with our market-making bot to execute the strategy. They ended up performing extremely well.

We saw one more interesting strategy used although, ethically, it was questionable. Remember how we mentioned that we didn’t support native XLM since users could get as much as they wanted from Friendbot? One user took over 15 million XLM from Friendbot and used it to create offers to buy assets supported by the protocol on the DEX. They got a couple of users with this strategy and managed to gain a few million extra EURT.

Takeaways for YieldBlox

We learned quite a few things from the beta and will be making modifications to the YieldBlox protocol to improve performance and UX.

1. Removing 2-step deposits:

Previously, to lend assets, users had to first create a claimable balance in one transaction, then input the claimable balance id into the smart contract to deposit into the protocol. This was to prevent a small exploit where the time gap between transaction creation and submission made it technically possible to skim protocol fees. We quickly realized that these non-atomic deposits were a huge UX issue. Users would submit the claimable balance transaction. Then, if the deposit transaction failed for any reason, the funds would appear lost! While users didn’t actually lose funds since they could simply reclaim the claimable balance, it was a large UX issue, as many users were not familiar with how to do so. We’ve decided to remove 2-step deposits and institute a small withdrawal fee instead to prevent the previously mentioned vulnerability.

2. Changing sYBX calculations:

Previously, sYBX value calculations (how we determined how much YBX an sYBX is worth) awarded retroactive fees to stakers since we paid out a flat amount of sYBX based on the staking multiple. Technically, this was economically sound because of the staking lockups, but it’s just as un-intuitive and confusing as it sounds. We’ll be changing the calculations so that sYBX is valued and issued more like a pool token.

3. Adding a collateral toggle to staked YBX

Many users brought up that they would like to choose whether their staked YBX is used as collateral for their borrow positions. We think this is a great idea, and increases the flexibility and usability of staked YBX.

4. Allowing users to specify which type of loan they would like to repay (choosing between fixed or floating rate loans)

Originally, when a user decided to repay a loan, if they had both a fixed and floating-rate loan for that asset, the smart contract would proportionally divide the repayment between the two loans. This was extremely confusing and didn’t mesh with the UI. As a result, we now allow users to specify which type of loan they’d like to repay.

5. Storing info in claimable balance claimants gets pretty gnarly

We track liabilities in claimable balances on chain, and use a claimant predicate to also track the loan’s accrued interest. This is done as a UNIX timestamp, which is represented in the predicate as a ISO 8601 timestamp. To our surprise, Horizon and JavaScript actually use different ISO 8601 representations, since this format isn’t consistent for times past the year 9999. We got around this by adding a custom ISO decoder to our protocol after realizing it was an issue, and hardened our protocol against any unexpected results. Kudos to the beta testers for finding this one!

Takeaways for Turrets

As the YieldBlox beta was the first instance of a large-scale DeFi protocol using Stellar Turrets, we learned a lot about building DeFi with turrets — the main one:

Horizon is not optimized for Turret workflows

Our protocol has to make a lot of API calls to use Horizon safely. This high traffic resulted in some of our contract runtimes taking upwards of 30 seconds. The takeaway is that we need to build a custom Horizon instance for turrets to cut down on the API calls we have to make.

Beyond this, we were thoroughly impressed with the usability and performance of Turrets. Debugging issues in the protocol felt natural, and the overall volume the Turrets managed was impressive. Further, the cost of hosting all three Turrets was minimal. We processed ~48k contract executions across three Turrets, and only incurred ~$15.35 in hosting fees. This is approximately $0.0001 of fees accrued per Turret per contract execution (and our contracts were slow)!

What’s next for YieldBlox?

Now that the official Beta is over, we’re going to be heads-down working on getting the full protocol audited and released, probably by the end of November, as there’s a lot of work to do. We’re also going to be finishing those technical docs we’ve been promising for so long, and hopefully getting an API and SDK together. Additionally, we’re hiring for business development, marketing, and engineering roles, so please reach out if you’re interested in building DeFi on Stellar. Thank you all for accompanying us on this journey. We can’t wait to see what’s next!

Don’t Forget about the Staking Page!

Join our community!

@script3official / Discord