Participant(s) make a Sovryn Improvement Proposal (SIP) , which is written here and iterated in code if approved by the community.
…"
How is this iteration to code working in detail? (After SIP is voted to approval)
Personally, I really like the ability for non-developers to engage and submitt SIPs.
It also makes voting easier, or let’s say possible for all kinds of stakers, cause of human readability.
As much as I like that approach, doesn’t it open doors to individual (or group) decisions of “how to implement” a SIP?
I don’t mean the nitty gritty technical details but the full transfer of SIP text and context of “what should happen” into “that’s the code for it”.
I guess the implementation opens a lot of freedom on interpretation? (And more of that if developers votes are opposed by majority).
Not that I insinuate such behaviour, but just interested in the process of it.
Someone who has an idea for a SIP that requires a code change (e.g. smart contract addition/update) will either have to write the code themselves or find a competent Solidity developer to write the code for them.
But what about all last SIPs?
They were human readable, still someone had to put them into code.
Yes, if the authors themselves weren’t coders then they found a coder who was willing to implement any code needed.
I do think that going forward it will be necessary to see how the human-readable proposals are translated into code. So far I do not think this is clear in the governance interface and should be improved if such improvements are not already in the works. See for example how code-based changes are presented in the Aragon Voting app: https://client.aragon.org/#/network/0x240b4de6000b4ad52ceaa1057c2647bfc24ce697/vote/13/
Currently, the code which is executed on a proposal is shown below the description. We should decode the ABI-encoded parameters to make them more readable, but in general, the information is there, already.
In case that the SIP does update a smart contract logic, the contract which will be replacing the existing one, will be visible as parameter. This contract has to be verified on the explorers, so anybody can investigate.
Suppose we have to call the function deposit in Contract A with the parameter 100.
Then in the proposal, it will be mentioned:
Which contract to call: Contract A Address
Which function to call: deposit
Any parameters: 100
Once the SIP is approved from majority, these parameters are sent to a protocol contract, and there it calls the deposit function in Contract A with 100 as the parameter.
At the moment Sovryn does not have it in the frontend, but surely you can create an SIP, and the Sovryn Team can either make the code call part for you, or can verify the part which some other community member created (we have really active community).
You could also check out a website like these: https://abi.hashex.org/ to create the code to be executed. Though that might also need some level of Technical knowledge.
As @Ororo said, at the moment we have the details shown under the proposal. Some of these values might see gibberish, because it is made such that it is easy for the machine to read it, even though it makes us look confused. Those are encoded forms of the data we wanted to send.
Let’s go back to the earlier example, if we use the hashex website mentioned earlier, we can see that, the transaction detail will be as below for the deposit() with parameter 100:
Where the first 8 letters tells us the function we would be calling, i.e. the deposit function
And the rest of the value 000...0064 mentions the parameter 100 (It is encoded in hex, 6*16^1 + 4*16^0 = 96 + 4 = 100)
Sorry for the detail above But I believe all our SIP’s currently contain the details of what will happen on approval of the SIP, and what would be the after effects of it.
Thank you very much for that detailed answer! Greatly appreciated!
Then I maybe got it wrong in the first place already.
I thought that, for example, when Yago proposes a SIP (it’s nicely written, well thought out, etc…) and it passes voting… that THEN someone from the team goes ahead and implements changes… according to what’s written in that nicely readable doc.
Exactly that transfer from doc to code (who makes it, oversees if all details from doc are exactly like they should be/voted for, etc…)
But your explanation (and the ones before) makes much more sense now to me now.
But I believe all our SIP’s currently contain the details of what will happen on approval of the SIP, and what would be the after effects of it.