securesecrets / shadegrants Goto Github PK
View Code? Open in Web Editor NEWGithub repository for Shade Protocol grant submissions.
Github repository for Shade Protocol grant submissions.
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.
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:
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.
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.
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:
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.
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.
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”.
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 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.
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.
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.
The main KPIs for Silk Pay are as follows:
Steven
Btn group
Btn group github repo
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:
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.
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.
A multi-pool stable set up combined with the SilkSwap invariant that will encourage Silk adoption and protect Silk during periods of volatility.
Stableswap
Silk liquidity
Silk utility
More efficient stableswap implementation
ShadeSwap adoption
Canaro86
PHD in Mathematics
Successfully created the SilkSwap invariant outlined here
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.
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.
Children get cancer and need treatment. Caregivers need money to live in a capitalist framework.
swap funds to bitcoin and send to charity
creates a positive world environment in which to thrive.
Proposal submitter would also like a payment of 0 SHD to pay for proposal cost re-imbursement
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.
Swap fees create a capital inefficiency in maintaining the silk peg by arbitrage
proposal type for weekly liquidity buys and monthly LP allocations
smoke weed everyday
The main KPIs for Shade Protocol is TVL, feeless swaps for protocol components and a revenue stream to the main treasury
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:
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.
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.
Assume that Silk starts at ~$1.05
Assume that Silk will change, at most, +/- ~$0.02 worth of volatility annually
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).
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
Number of users
Silk Adoption
Liquidity Adoption
UX on Silk acquisition
DEX adoption
Canaro86
PHD in Mathematics
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.
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.
discord needs an active, thriving, contributing community
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)
helps community members feel engaged and hopeful that they will receive compensation for positive community involvement
This proposal is for work already completed and any further funding would require additional proposals
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.