opensystm / handshake-micro-grants

12 stars 5 forks source link

Lockup Loans: Staking on Handshake #2

Closed Anunayj closed 8 months ago

Anunayj commented 1 year ago

Introduction

I'm Anunay, I've contributed to hsd in the past in a few small ways (1, 2).

Proposal: Lockup Loans

or Staking on Handskake

Bids on the Handshake network can be masked using a higher lockup amount than the bid itself, refunding the difference (aka the blind) after the auction. This conceals bids to avoid getting outbid by a dollarydoo, but still sets an upper bid limit and ties up funds.

Solution

Since the blind (lockup_value - true_bid) is refunded to the user post-auction. One can issue a "loan" of that amount for the duration of auction. This benefits those with surplus holdings, letting them earn interest (similar to "staking"), while boosting bidder privacy.

But can it be decentralized?

Doing so on a centralized platform is pretty straightforward. However, pinheadmz suggested a possible approach to do this non-custodially during the last handycon. Unfortunately nobody really came forward with a implementation because of the immense complexity of the project.

I have a slightly modified from original approach documented here. Much of the ideas used here are thanks to Matthew Zipkin and Fernando Falci.

Original Approach by pinheadmz.

Techical Details for modified approach

Completion Criteria

  1. Research, and document possible approaches. (A HIP possibly)
  2. Implement a reference implementation (a integration test perhaps) covering all edge cases.
  3. (Optional) Implement a library (similar to shakedex) that can be used by various wallets (and stakers) to facilitate lockup loans.
  4. (REALLY OPTIONAL) Use Adaptor Signatures in the implementation because using NOINPUT wasn't already scary enough that we're now playing with real cryptography.

Timeline

I understand the project timeline is limited to a maximum of 4 weeks. However, considering the complexity and potential impact of this project, I suspect it would take atleast 8 weeks to ensure a thorough and well-tested implementation. This proposal can possibly be split into two (or more) parts (possibly worked on by multiple people!?): Research, Documentation and Implementation.

Sidenote

It's crucial to acknowledge the potential dangers posed by any flaw in the implementation. A critical flaw could result in irreversible loss of funds. Rigorous testing is essential to mitigate the risk of such flaws, and honestly I feel a little unqualified to do this alone.

Contact Information

Email: me [at] anu [dot] ninja Discord: @anu9001 Telegram: @anunayj

Anunayj commented 8 months ago

Check out this blog post for details on the protocol development.