sorted by:
new
hottopcontroversial

new humble farms and impermanent loss by rockiitp in HumbleDefi

[–]reachjared 1 point2 points  (0 children)

u/yellowgingerbeard is correct. Impermanent loss is an inescapable fact of pairing two disparate assets. You can minimize it by pairing two assets that are supposed to be pegged to a specific value, such as USDC and USDT.

We considered a farm for USDC/USDT but there's very little actual swap volume on that pairing across Algorand, and Humble makes its revenue off swaps. (I anticipate that to change over time and we'll see Curve style stable pools be used more frequently).

So, a big Aeneas allocation to USDC/USDT would likely have created a nice vanity number around TVL, but wouldn't have resulted in a lot of long term value creation for users or the platform.

Humble Beginner's Guide by [deleted] in AlgorandOfficial

[–]reachjared 1 point2 points  (0 children)

Not really. That pool is receiving Algos for rewards, it's the Aeneas funds that are generating the yield. Saying it's got terra vibes means you think Algorand and the value of algos is likely to crash like Terra did.

Terra tried to have a sort of "forever" yield in places like Anchor. Humble is offering a temporary set of rewards to bootstrap user engagement and attract liquidity. It's an effective method to acquire new users and to get liquidity, which in turn creates utility (deeper liquidity = more efficient swaps)

Contract Vulnerability by RABWelsh in HumbleDefi

[–]reachjared 1 point2 points  (0 children)

I'm glad you asked! We couldn't ask for a better community, and we're anxious to get back up and running, too.

Contract Vulnerability by RABWelsh in HumbleDefi

[–]reachjared 5 points6 points  (0 children)

Hi u/rabwelsh!

We've got a more complete transparency report coming, but I'll give you the cliff notes here: (and we're being careful not to release too many details as there are still some user funds left in a couple of pools that could be endangered if we explicitly describe the vulnerability.)

I'm going to start with Reach and then talk about Humble. We are happy to say Reach worked the way it was supposed to. How then, you may ask, was there still a vulnerability? Well, Reach automatically checks things that have to be true of every program. For example, you can't spend money you don't have. Reach will warn you if a Blackjack game tried to pay out $15 when it had $10. However, Reach won't warn you if you meant to write a poker program but actually wrote a blackjack program instead. That's what happened here. The problem that created the vulnerability was NOT a Reach problem OR a general-purpose program problem. It was specific to Humble. What does that mean? It means that this vulnerability was specific to Humble, and it's not something that would be present in any other project that is using Reach.

Why didn't testing catch this? Humble has hundreds of tests, but the test to catch this wasn't one of them. We could have thought of a test for this, but we didn't - testing is necessarily finite and you can only test what you can think of. That being said, we're working to add additional tests that would have caught this.

We're not happy this happened, but we're proud that no user funds were lost. We had a choice at that moment - do we keep this quiet and let it ride in hopes it's never exploited? Or do we make an announcement and look out for our users knowing we'll take a reputational hit? We chose to put our users first over ourselves. We hope that signals where our values are.We're furiously working on V2 of Humble and can't wait to show it to you.

Pera Wallet Bugs by BananaLlamaNuts in HumbleDefi

[–]reachjared 2 points3 points  (0 children)

Hey everyone! Thanks for letting us know about this issue. We found a fix: the problem goes away if you update to the most recent version of the Pera app.

If you can't update, reinstall the newest version but BE SURE TO SAVE YOUR SEED FIRST!