Silk Pay Grant (Claimed)

Silk Pay Whitepaper.pdf

Project Description

One of the key barriers of adoption for cryptocurrency transactions is the transfer of large amounts of capital between entities. Test transactions are a popular mechanism by which users check to make sure they are sending to the correct counterparty by sending a non-consequential amount of cryptocurrency to a target address. However, this does not create a true sender/receiver confirmation system as every “fresh” transaction can create a risk of destination error user input during the new send. Additionally, transactions on blockchains are traditionally completely transparent - exposing users’ privacy and transaction history.

Enter Silk Pay - a privacy-preserving payment application built on Secret Network that introduces a new sender and receiver confirmation architecture that empowers senders to escrow capital in a contract while awaiting intended counterparties to confirm the inbound transaction by interacting with the escrow contract. Using the send request and receive request architecture, Silk Pay ensures outbound capital both safely and consistently sent to the correct location, enabling peace of mind and usability for everyday users.

Problem / Solution

Silk Pay is a simple payment application focused on the SNIP-20 token sending and receiving user experience on Secret Network. The primary goal of Silk Pay is to bring Silk, the privacy-preserving stablecoin of Shade Protocol, to everyday end users in a safe and comfortable way. The initial implementation of Silk Pay is focused on a web experience, with future iterations to be built directly on mobile. Silk Pay is uniquely differentiated because it solves the jarring and risky “wire-transfer” paradigm of the majority of Web3 user-to-user transactions. Silk Pay solves this by giving users a varying degrees of sending and receiving options:

• Send Request
• Receive Request
• Direct Transfer

Direct Transfer (DT) is the traditional method of sending funds using the traditional wire-transfer architecture. With DT, users specify X amount of funds to be sent to Y address. Upon execution of the transaction, if the destination address is incorrect or improperly input, there is no recourse. Note that there is no transaction confirmation from the counter-party prior to funds being sent with the DT architecture. All double-checking has to be done in advance of the transaction - introducing risks as each send transaction user interaction carries its own set of risks for potential mis-step. To date, DT is the standard means by which users send funds.

This is what the send request and receive request architecture is created to solve. Using escrow contract architecture, users can privately send X amount of funds to an encrypted destination address using a multistep process that involves confirmation interactions between both the sender, receiver, and escrow contract. As such, this architecture ensures that senders only ever send funds to correct addresses that are confirmed but the intended counterparty. Additionally, request infrastructure allows users the flexibility to privately request funds from other users. Eventually, Silk Pay will also include a system of monikers and registered addresses to make the initiation of a send or receive request even easier. While vetted addresses can remove the need for send request methodology (as send request is essentially a destination verification system), there will always be the need for send request architecture for first time transactions. With the incorporation of monikers and registered addresses, receive requests become an even more seamless UI/UX experience.

Detailed product description

Send Request
Send Request (SR) architecture is a six part process (2 parts for sender, 1 part for receiver, 3 parts contract) that ensures the safe arrival of funds to intended destinations via a system of confirmations between the sender, receiver, and escrow contract. With the SR model, senders await confirmation from an escrow contract that interacts with the intended destination address.

Traditional Web2 payment request models involve users requesting a certain amount of funds from a counterparty, which the counterparty has the option to confirm. SR flips the traditional request model by instead having the sender initiate a “send ask” before funds are sent. A send ask is viewable by the potential counterparty, who can then create an inbound confirmation that is viewable by the sender. Upon seeing the inbound confirmation, the sender is guaranteed that the target destination address has been properly targeted, allowing the sender to safely perform an execute send.

Send Request User Story

• Bob creates a send ask, which is first staged in the escrow contract
  100 SCRT
  secret1zfk9yoptw7nlnwc4r66d84rgc3cqpd7hynczgq as the address he believes to be Alice
• Alice queries the escrow contract, expecting a send ask for 100 SCRT
• Alice does not see a send ask, and let’s Bob know asynchronously
• Bob retracts funds from the escrow contract and destroys the original send ask
• Bob sends another send ask to the escrow contract, realising the address was wrong
  100 SCRT
  secret1zfkzyzptw7nlnwc4r66d84rgc3cqpd7hynczgq as the new address he believes to be Alice’s
• Alice queries the escrow contract, and sees the incoming send ask
• Alice creates an “inbound confirmation” that gets sent to the escrow contract
• Alice can send an asynchronous message to Bob that send ask was received and that she successfully generated an inbound confirmation
• Bob queries the escrow contract, and sees the --inbound confirmation-- for his potential transaction
• Bob performs the execute send, funds are sent to Alice

Send Request Risks

There is a potential risk that Bob potentially uses an address of another user who is not Alice, and that the malicious user would create an inbound confirmation for the escrow contract in hopes that Bob would perform an execute send after seeing the inbound confirmation. There are two safeguards against this:

• Possible addresses on Secret Network are 2^160 = 1461501637330902918203684832716283019655932542976 = 1.4615e+48. The odds that you accidentally put an address in that has an existing counterparty that is prepared to send an inbound confirmation message has less likelihood than a user accidentally sending to the wrong person on Venmo or PayPal by an order of magnitude.
• Due to Silk Pay being focused on A to B intermediary, it is highly unlikely that a Send Request is sent to a counterparty that does not have some form of asynchronous communication coordinating on the sending and receiving. That is to say, it will be highly obvious when a send-ask has not been received, with responsibility ultimately resting squarely on the sender for the final execution of the execute send.

In order to give senders maximum amount of flexibility, Senders will have the ability to perform an execute send prior to receiving an inbound confirmation from the receiver. Note that this will be highly discouraged within a UI/UX experience, but ultimately will be up to the user.

Receive Request

In addition to SR, there is also the Receive Request (RR) architecture which many users are already familiar with in Web2 that mirrors the traditional payment request operations.

RR User Story

• Bob creates a receive ask, which is first staged in the escrow contract
  Origin address
  100 SCRT
  secret1zfk9yoptw7nlnwc4r66d84rgc3cqpd7hynczgq as the address he believes to be Alice
• Alice queries the escrow contract and sees the receive ask for 100 SCRT as well as which address created the receive ask
• Alice can asynchronously check with Bob that he is the owner of the address and that he made the request
• Alice performs an execute send on the receive request
• Bob receives his requested funds from Alice

If Alice let’s Bob know that she did not get the receive ask, Bob can retract the receive ask that was originally created by him. One of the risks of the Receive Request architecture is users could spam popular addresses requesting funds. Recourse for this behaviour is spam filtering on the front-end where users will only see receive asks from addresses they have already registered on the escrow contract as “contacts”.

S/R High Level

The end result of Send/Receive architecture is a simplified experience that empowers users to safely send funds to new counterparties in a controllable manner that is managed by an escrow privacy-preserving smart contract. Users will still have the flexibility to send funds “wire-transfer” style with Silk Pay, but this will generally be discouraged (unless an “address book” or “moniker” contact is used). Cryptocurrency transactions require both privacy, security, and usability. Silk Pay using this brand new Sender Request architecture will help bring Web3 comfortably to Web2 users.

Silk Pay Fees

Silk Pay is a key primitive of Shade Protocol - empowering an entire suite of privacy-preserving DeFi applications. Direct transfer payments will not be charged any additional fees, as this is simply a “normal” transaction by blockchain definition. Whenever a SR or RR is generated or executed upon, a small additional flat rate gas fee will be generated and sent to the Shade Protocol treasury address - creating an additional revenue stream for Shade Protocol SHD stakers.

Conclusion

The next generation of payment applications must ensure users have a way to safely send to new addresses with large amounts of capital. Current architecture in blockchain is essentially a blind wire transfer with no recourse for mistakes. By leveraging Secret Network’s privacy via secret contracts, Silk Pay provides a best in class experience that is currently unmatched by any other payment verification platform on Web3.

Go-to-Market plan

Silk Pay will be published to shadeprotocol.io/pay - adding to the larger Shade Protocol application experience. Silk Pay will include videos and tutorials to explain why you should always use Silk Pay “Safe Send” and “Request” methodology over alternatives.

Value capture for Shade Protocol ecosystem

The main KPIs for Silk Pay are as follows:

• Number of users
• Fees generated
• Number of Silk transactions
• Number of SHD transactions
• Number of SNIP-20 transactions

Team members

Steven

Team's experience

Btn group

Team Code Repos

Btn group github repo

Development Roadmap

The creation of Silk Pay will purely involve the creation of the required Secret Contracts, with a barebones UI/UX and documentation to prove the contracts are functioning as intended. Later on, the core contributors will incorporate the core contracts into the primary UI/UX of Shade Protocol.

Example milestones:

• Implement the Send Request & Receive Request Secret Contracts (weeks 0 - 6)
• Implement MVP front-end to prove functionality (weeks 6 - 10) & thorough documentation of contracts

Completion of milestone one will result in 1k SHD. The completion of milestone two will result in 1k SHD.
At current market prices (~$50) this amounts to approximately $100,000 worth of SHD.

Project Description

Convert the SilkSwap invariant to be compatible with a 3-pool & 4-pool set up on ShadeSwap. Additionally, include [REDACTED] innovation on existing stableswap to improve capital efficiency for large trades. The creation of a multipool will help build stability for Silk as well as additional utility. This multipool can become the focal point of Secret Network & Cosmos liquidity, while also maintaining key privacy properties that empower private trades and DeFi interactions.

Importantly, the conversion of the SilkSwap invariant to a multipool set-up must ensure that reasonable gas fees are maintained during the computation.

Result

A multi-pool stable set up combined with the SilkSwap invariant that will encourage Silk adoption and protect Silk during periods of volatility.

Research Value Capture

Stableswap
Silk liquidity
Silk utility
More efficient stableswap implementation
ShadeSwap adoption

Team members

Canaro86

Team's experience

PHD in Mathematics
Successfully created the SilkSwap invariant outlined here

Development Roadmap

The creation of the multipool invariant using the previously research StableSwap invariant is broken up into three milestones

Milestones:
Preliminary Research (weeks 0 - 5)
Model Presentation / Simulation / Documentation (weeks 5 - 10)
Psuedo Code Implementation (weeks 10 - 13)

Completion of milestone one will result in 500 SHD. The completion of milestone two will result in 1.5k SHD. The completion of milestone three will result in 500 SHD + $5,000 USDC. Total: 2,500 SHD + $5,000
At current market prices (~$10) this amounts to approximately $30,000.

Shade Charity

Project Description

This is an application for a grant for a 420 Shade crypto currency donation to St. Jude Children's Hospital in the form of Bitcoin to
St. Jude Crypto Donations

St. Jude is leading the way the world understands, treats and defeats childhood cancer and other life-threatening diseases.

Problem / Solution

Children get cancer and need treatment. Caregivers need money to live in a capitalist framework.

Go-to-Market plan

swap funds to bitcoin and send to charity

Value capture for Shade ecosystem

creates a positive world environment in which to thrive.

Team members

• zenopie

Proposal submitter would also like a payment of 0 SHD to pay for proposal cost re-imbursement

Silk Swap Team

Project Description

This is an application for a grant for silk swap:

We intend to create a swap on Secret Network. Use of this swap will increase the capital efficiency of Shade Protocol and enable feeless swaps of protocol necessary components

Our team has been closely following Ethereum DeFi and Secret Network in the last year, and are active in the chat channels. Needless to say, we are really excited to see this project evolve.

Problem / Solution

Swap fees create a capital inefficiency in maintaining the silk peg by arbitrage

Detailed product description

proposal type for weekly liquidity buys and monthly LP allocations

Go-to-Market plan

smoke weed everyday

Value capture for Shade ecosystem

The main KPIs for Shade Protocol is TVL, feeless swaps for protocol components and a revenue stream to the main treasury

Team members

• Braydn Larsen (zenopie)
• your mom
• your dad

Team Website

• https://www.youtube.com/watch?v=PIb6AZdTr-A

Team's experience

• cleaning toilets
• wiping up shit
• dusting

Team Code Repos

• https://github.com/zenopie/EarthNetwork
• https://github.com/zenopie/HumanityDAO
• https://github.com/zenopie/AnimalSwap

Development Roadmap

We will require 3 months to complete this project. We intend to have 2 developers full-time and 1 part-time with unknown costs to human spirit and body

Example milestones:

• Implement treasury (weeks 0 - 4).
• Implement pairs (weeks 4 - 8).
• Implement proposals (weeks 8 - 12).

Ideally, we can receive payments in 3 disbursements, one at the beginning of the grant, one after implementation of pairs and last payment when the development work is completed.

I would like to be paid $250,000 in shade through a 3 year linearly unlocked staking contract with the ability to change my staking risk level and claim staking rewards

Silk Invariant Research [Solving USD/SILK StableSwap Curve] - (TAKEN, open to additional team members)

One of the most unique innovations that has emerged within DEX design are StableSwap invariants - mathematical curves that differ from traditional constant price invariance curves. StableSwap invariants differ because of the design assumption that two assets will be trading at a similar price, or at least at a stable ratio between the two assets (USD stable / USD stable).

Due to the change in the invariance curve, fees and slippage are significantly reduced - creating a much better trading experience and liquidity providing configuration. StableSwap still inherits key attributes that are similar to other DEXs. Specifically, infinite liquidity with increasingly worse slippage the more volatility and derivation that occurs.

StableSwap Invariant (Curve):

Problem

Silk faces a distinct mathematical headwind that needs to be solved for: the price of Silk is stable in relation to other stablecoin assets (such as the dollar), but with a degree of volatility due to the peg slowly shifting on a multi-year basis.

Assumption:

Assume that Silk starts at ~$1.05
Assume that Silk will change, at most, +/- ~$0.02 worth of volatility annually

Solution:

A middle-ground stablecoin invariant curve that is able to reflexively adjust to Silk’s slowly changing peg, while also operating with minimal fees and slippage due to the design assumption that the ratio between a USD stablecoin and Silk should be continually stable on a day-to-day basis (but not perfectly 1-to-1, and with variant over extended timeframes).

End Result:

A curve that can be used by any stablecoin DEX that wants to implement USDC/SILK, UST/SILK, USDT/SILK into a curve-like product. Because of the mass adoption of USD stablecoin pairs, it is unlikely that DEXs will perform this research on their own. As such, this grant is building for a future end state where we see a transition from USD centric stablecoins to alternative decentralised and non one-to-one sovereign currency pegged stablecoins. This research could hypothetically empower other non-USD but highly stable stablecoins. It is theorised by the designer of this grant that modifications to existing StableSwap invariant curves will not necessarily be that large, but potentially will have significant ramifications to the sustainability of such a product.

Stableswap Reference Research:
https://curve.fi/files/crypto-pools-paper.pdf
Curve StableSwap: A Comprehensive Mathematical Guide
StableSwap-paper
Understanding StableSwap Curve

Research value capture for Shade Protocol ecosystem

Number of users
Silk Adoption
Liquidity Adoption
UX on Silk acquisition
DEX adoption

Team members

Canaro86

Team's experience

PHD in Mathematics

Development Roadmap

The creation of the USD/SILK invarient is broken up into three milestones

Example milestones:
Preliminary Research (weeks 0 - 3)
Model Presentation / Simulation / Documentation (weeks 3 - 10)
Psuedo Code Implementation (weeks 10 - 13)

Completion of milestone one will result in 250 SHD. The completion of milestone two will result in 1.5k SHD. The completion of milestone three will result in 500 SHD. Total: 2,250 SHD.

At current market prices (~$50) this amounts to approximately $112,500 worth of SHD.

Shade Hoplites

Project Description

This is an application for a grant for shade hoplites from community funds:

in order to better serve the community the hoplites humbly ask for an allowance of 200 SHD plus proposal cost (0 SHD) equally split between Hoplites

Our team has been closely working with the community to answer questions, solve problems, create generative conversation and engage and educate the discord community.

Problem / Solution

discord needs an active, thriving, contributing community

Go-to-Market plan

send funds to hoplites equally and think about creating a hoplite treasury in the future controlled exclusively by hoplites (extendable to other roles. ahem community mods cough cough)

Value capture for Shade ecosystem

helps community members feel engaged and hopeful that they will receive compensation for positive community involvement

Team members

• zenopie
• mindtrap

Team's experience

• educating
• helping others
• engaging community

This proposal is for work already completed and any further funding would require additional proposals