How To RFP, Proposing New Functionalities to Polkaswap and the SORA Network

SORA

Published in

SORA

8 min readOct 7, 2021

TL;DR

By submitting Request for Proposals (RFP), users can tender the development and implementations of functions they would like to have in Polkaswap and the SORA network
Because SORA is decentralized, anyone can participate in the sustainable development process by submitting an RFP for the community to veto
The RFP process is quick and inclusive, even for those with little technical knowledge

Normally, within centralized projects, the community would pressure the team of developers by constantly asking wen, wen, wen. This in turn would serve as a guide for said team to orient their development process based on the community’s needs and desires (aligned with their own agenda).

In a fully decentralized project, the community has the privilege and responsibility to contribute to the continued development and improvement by submitting their proposals and subjecting them to community debate to weigh the advantages and benefits of such implementations. As the SORA network and Polkaswap are fully decentralized, all community members can submit their own RFP for consideration following a series of simple steps.

Contributing to the Decentralized Development Process

As of July 2021, the SORA and Polkaswap Decentralized Development Process has been open to submissions from the community to propose, in a non-technical manner, changes that they would like to see implemented (whether they are picked up and coded is another matter). There is another aspect, however, teams of developers that have the expertise to implement these changes themselves can also propose them, and if approved, their code could be incorporated into a runtime upgrade and they would also get rewarded for the work provided.

All the RFP should be submitted to this GitHub repo and will be publicly available to everyone

The process is the same for both types of would-be contributors, let’s outline the steps:

The individual or team create a draft on GitHub
Users on GitHub debate the RFP and decide whether to implement changes, reject or merge it to the repository.
The RFP is publicly announced on GitHub, along with its respective deadline and development team proposals.
The SORA community votes on-chain whether the RFP should be implemented, and if approved;
Responsible team or individual will work on the code as per their proposals, which will then be released and reviewed by users on GitHub, followed by subsequent runtime implementation and compensation upon merging.

For those who are not experienced in GitHub, but consider that their (non-spam) submission could be valuable, here is a quick walkthrough to get you started:

The RFP format requirements outlined within the walkthrough apply to all contributors.

RFP for Beginners; Draft, Branch, and Merge

Begin a draft on a notepad application (or your favorite markdown editor) for your RFP, this should include a solid and descriptive title outlining your submission. For the content the following format should be followed:

Proposal due date: This is the date of submission of your proposal
Proposal overview: Use this space to outline your proposal and what it is about
Proposal goals: What does your proposal seek to achieve? How will it benefit the current technology and community if it is approved? (“Making me more money” is not a benefit)
Scope of work: What needs to be done in order for your proposal to be implemented? Is all the technology available? If not, what other functions need to be implemented for your proposal to work flawlessly? Do you have more details or examples?
Current roadblocks and barriers to success: This point is self-explanatory, but it helps to define what could be an impediment to a smooth implementation of your proposal, as well as hinder its flawless operation
Evaluation metrics and criteria: What will your proposal look like when it’s done? What will people be able to do with it and what will the advantage of this implementation be? Will there be any changes to the UI/UX? Will additional resources need to be coded for this to work without a flaw?
Submission requirements: What is needed to provide for your submission to be executed? What additional technology will have to be implemented alongside your submission?
Submission method: Where will your proposal be submitted within GitHub? If you have studied the SORA repositories and know an exact place to put it, add that URL here, if not, then simply list https://github.com/sora-xor/rfps/tree/master/open_rfps
At this point, you can add a proposed due date, if you are aware of the amount of time it will take for your submission and its additional resources to be ready. This field will not be established until your proposal has been implemented (step 4 in the DDP).
Another optional detail is Budget amount, how much XOR will this implementation require for development man-hours? This can also be added to the proposal at a later time after it has been deliberated in the DDP’s 4th step, however, it is recommended to include an approximation of the man-hours it will require for completion.

Once this concise document has been drafted, it is time to add it to the GitHub directory.

The first thing you need to do is fork this repository to your GitHub so you can create a pull request

Within your fork, navigate to open_rfps then click on add file, you can either create a new file and copy/paste the contents of your document into GitHub, or you can save your document as a .md file and upload it. Either way works.

When you are done, commit the file directly to the branch of your choice. You are now ready to create a pull request to add your RFP to the SORA-XOR directory.

From your fork start a new pull request

Make sure that the base repository is pointing at sora-xor/rfps
Make sure that the compare section is pointing at the branch you want to merge from your repository
Click on create pull request

Once you have created the pull request, you can add some context to your request, along with a title. You can then submit the pull request or save it as a draft if you are not ready to submit it yet.

After you have submitted your PR, it will be available for the community to read, edit and review before merging. They will also be able to add comments, so keep an eye out for ongoing discussions happening within your PR.

After it has been reviewed, the proposal will be merged once it has enough approvals.

If you have already submitted an RFP and would like to submit another, it is very important that you create a new master branch for each RFP, so that you only merge one file submission for each proposal. If your proposal has more than one file, it will not be accepted.

Once the proposal is merged, then work can begin on its implementation!

It is that simple to submit an RFP! If you have any doubts about the content of your proposal, take a look at the pull requests submitted so far, you can get some inspiration on how to write your own.

The RFP repository mentions that trade secrets and other non-public information should never be included in any proposals, it is important to repeat that here as all the information submitted will be fully public and open, make sure to take that into consideration as well when drafting and submitting a proposal.

Finally, the RFP proposal process will be used for community-funded development, however, if there is any entity that wishes to use its own resources and funding to write code and propose it to be released on the SORA network without going through the RFP proposal process, they are welcome to do so.

About SORA, Polkaswap, and Fearless Wallet

SORA is a new economic system aimed at creating a supranational multiverse economic system with built-in tools for decentralized finance (DeFi). The SORA network implements a new way of parachain architecture on Polkadot and Kusama network, with the capability to bridge external blockchains (like Ethereum) to the Polkadot ecosystem.

One of the DeFi applications that will run on the SORA network is Polkaswap, a non custodial liquidity aggregating, cross chain AMM DEX designed uniquely for the Polkadot ecosystem with boundless liquidity through its one-of-a-kind Aggregate Liquidity Technology (ALT).

Fearless Wallet is a mobile wallet designed for the decentralized future on the Kusama and Polkadot ecosystem, with support for iOS and Android platforms. An awesome user experience, fast performance, and secure storage for your accounts. Fearless Wallet will integrate Polkaswap for easy, decentralized swaps of assets.