Stablehedge

Tokens
#1

Market volatility has been one of the common problems in crypto that hinders its adoption. We introduce Stablehedge as a solution to address this challenge. Stablehedge is DeFi (decentralized financial) platform built on BCH blockchain where users can peg their BCH’s value based on an external asset (e.g. USD). The solution uses tokenization to provide a simple user experience and Anyhedge’s leveraged shorts to peg their value against the external asset. Some of the core features in the platform are as follows:

  • Deposit: Users deposit BCH to the platform and receive a fungible cashtoken, called Stablehedge token, based on the current price of BCH against an external asset.

  • Redeption: Users can redeem back BCH using the stablehedge tokens received from deposit. The amount of BCH redeemed is based on the amount of tokens and the current price of its pegged asset.

  • Leveraged shorts: A portion of the total BCH deposits is placed in a 2x leveraged short position with Anyhedge to maintain that the Stablehedge token is peg to the external asset.

This paper shows the underlying architecture and the processes in the platform:

6 Likes
#2

Just to highlight something:

  • the peg mechanism is custodial
  • treasury / backing is fully transparent
  • minting / redemption is permissionless
1 Like
#3

what do you mean “the peg mechanism is centralized”?

1 Like
#4

You hold the key(s) to autkeyNFT and treasury and you manually create AnyHedge contracts, right?

Maybe “custodial” would be a better word than “centralized”, edited.

#5

The authkeyNFT is used for rebalancing funds between Treasury and Redemption contracts. The funding of AnyHedge contracts is currently using multisig. We hold all the keys now in our alpha release, but the initial idea was that BCH Bull holds one of the of the keys so that they become a co-signer and we don’t have to hold all the keys. But we got an idea from @MathieuG how we can constrain the spending of Treasury funds to funding AnyHedge positions. We are still implementing this though. If it works, the movement of funds in the Treasury contract will be constrained to either going to Redemption contract or funding AnyHedge contracts. This will make it non-custodial.

2 Likes
#6

That’s not necessarily bad.

BCHBULL LP mechanism is also “custodial” or “partially centralized”, but that does not mean the service itself is “not safe” or “not good enough”. The oracles are also “centralized”.

True absolute decentralization is hard. In time, we may invent ways to decentralize all the things, but this is a huge amount of work. Rome wasn’t built in a day.

1 Like
#7

I’m not sure it’s worth it, because then you have to hard-code AH payout addresses else it could be used as an escape hatch (adversary just sets both addresses to an address he controls). It just moves the central point of failure to those hard-coded addresses.

What you have now is simpler and it makes the edges more obvious and state of things transparent, I think that’s good.

On Telegram, @mainnet_pat had a suggestion on how to increase trust: rate-limit how much funds you can move, maybe 10% daily or something. That way if keys of the kingdom would be compromised, holders could do a bank run and get at least 50% value back before adversary has a chance to sweep everything.

#8

Designing the system to be non-custodial is crucial for avoiding regulatory burdens. Under current regulations, holding custody of funds automatically classifies an entity as a money services business (MSB), triggering KYC requirements, the travel rule, and potential licensing obligations.

2 Likes
#9

ah ok, yeah that’s fair, but the cost is that it will be rigid: in AH contract party A will be your treasury and party B will be some fixed LP (or would you have some multisig or governance tokens allow changing the LP payout address?)

#10

One of the interesting guarantees of the AnyHedge contract is that hedges don’t face impairment losses when entering into a swap position.

So while bulls and shorts on leverage can be liquidated, the hedge position does not have a liquidation path.

If a large market participant wanted to bet against everyone in a country by hedging, the large market participant is not going to get wiped out in an extreme market event. Given a long enough time scale, the leveraged position will get liquidated.

#11

it does: when the contract runs out of bch to pay off a winning long - that’s when the hedge will get liquidated

1 Like
#12

In the bullish cash, if a swap ends early because the price exceeds the bounds of the contract, the hedge gets back their full principal (as denominated in the currency pair).

While the bull could go to zero, the hedge side cannot get completely wiped out TMU.

I can’t wrap my head around the converse case with a leveraged short. Are the risks at the bounds of the swap symmetrical or does one side have an advantage?

#13

ah yes, in case of price going up (in favor of long) the early liquidation doesn’t mean loss for the hedge position, it just means an early exit, and the hedge will have BCH released which they can use to re-enter a hedge position

if price goes down, the long side gets dust and permanently loses value

note that above proposal wouldn’t be using hedge but x2 shorts instead (so treasury can have 50% in liquid BCH + 50% in x2 shorts = net USD position), and those shorts would get burned on +100% price move

#14

It won’t be very rigid if we get to implement @MathieuG 's solution. His idea is to pass AH contract’s bytecode as a contract parameter to Treasury contract and pass the AH contract parameters as a function parameter in Treasury contract. Then inside the covenant, we combine AH bytecode and AH contract parameters to generate the locking bytecode to constraint the outputs.

So the LP payout can be different for each AH contract instance. It could be rigid in a way that the AH contract version will be fixed since it’s bytecode is passed as Treasury contract’s parameter.

2 Likes
#15

Yes, you can do all that (have treasury verify AH contract parameters and generate AH bytecode).

My concern was this: if Treasury operator can choose AH payout bytecode, can’t an adversary set both payout addresses to his own? Or, set LP’s address to his own and set other contract parameters so that it liquidates immediately in LP’s favor?

I guess you could have Treasury contract constrain AH contract’s parameters so much that it can’t be exploited to funnel money out, even if adversary takes control of Treasury.

#16

Thank you for pointing this out, perhaps we could limit some of the AH parameters to a fixed range (e.g. liquidation prices & duration). For the payout address, we can use OP_ACTIVEBYTECODE to derive the payout address on one side.