Simple Summary
As a distributed protocol enabling the creation of decentralized option markets, there should be some kind of incentive program available for community members to partake in, should they desire to set up their own contract interfaces. Ideas include some kind of stipend in the form of SI or a share of what could be called operator fees in exchange for providing the interface that users trade on.
Abstract
There are approximately ~200 countries on earth and thousands of spoken languages. Many people in these places do not have access to financial markets despite yearning to interact with them. This is especially difficult in emerging markets. Bitcoin, Ethereum and related technologies have been opening new doors for years now to overcome these difficulties. We’re now well into the onset of what is commonly referred as the rise of decentralized finance. Derivatives markets, like options trading are one component to this. As a distributed, open source protocol that facilitates this, the SIREN community should have some kind of incentive program for operators who would like to open the door to defi and decentralized, non-custodial trading in their countries, and the many languages that they speak. An incentive program would help these operators potentially earn income by doing so.
Motivation
The SIREN protocol is nascent and very new. Despite this, there has been interest in many different people from across the globe who realize the potential and possible implications of the tech.
Specification
The following are high-level specs that would need to be in order for there to be a comprehensive incentive program:
- Incentives
- Incentive timetable
- Performance based incentives
- Refined forkable codebase needed to set up contract interface
- Supplemental documentation
- Select open source license
- Some kind of antifraud/antiphishing measures like a directory of interfaces that people can reference to ensure someone isn’t impersonating the protocol interfaces with a scam website, among other things
Rationale
The incentives and associated timetable are obviously important as those will be keys to operators determining whether or not they would like to set up one or more interfaces. It also may make sense to have some sort of performance based component to recognize operators who perform better than others.
An easy, forkable codebase with solid documentation should be available to make it as easy as possible to get started. Also docs on risks and informing operators that they should check to make sure that setting up an interface is something one would be able to compliantly do in their relevant geographic area/jurisdictions.
Backwards Compatibility
At this time, it doesn’t seem that this sort of program would introduce any types of backwards compatibility issues.
Test Cases
There should be test cases for ensuring it’s possible to validate operator volume on top of the protocol. Also that the operator’s interface is up/available. These seem like the primary cases, but there may be several secondary ones. We should note them in this discussion thread.
Implementation
TBD once specifications are more granularly fleshed out.
Security Considerations
As mentioned in the specifications, it would be important to have antifraud/antiphishing measures like a directory of interfaces that people can reference to ensure someone isn’t impersonating the protocol interfaces with a scam website.
There should also be some kind of operator guide with best practices for serving up a reliable and secure contract interface.
Additional considerations will most likely arise and this section should be updated.
Copyright
Copyright and related rights waived via CC0.
- Yes
- No
0 voters