Ssal Deliverables

[MatteoPerona]

Milestone Delivery Checklist

• The milestone-delivery-template.md has been copied and updated.
• This pull request is being made by the same account as the accepted application.
• I have disclosed any and all sources of reused code in the submitted repositories and have done my due diligence to meet its license requirements.
• In case of acceptance, an invoice must be submitted and the payment will be transferred to the Polkadot/fiat account provided in the application.
• The delivery is according to the Guidelines for Milestone Deliverables.

Link to the application pull request: w3f/Grants-Program#1986< please fill this in with the PR number of your application.

[semuelle]

Hey @MatteoPerona, thanks for the delivery and sorry for the long wait. It took me a bit to understand the logic of the smart contract, as I'm not so familiar with commodities. Everything looks good so far, I just have a few questions about the functionality in general.

• Since only the buyer can finalize, how do you ensure that the seller actually receives the total? Are you planning any kind of (off-chain) dispute mechanism?
• You include volume, but no indication of the unit of measurement. Would each commodity have its own smart contract so that the unit is the same for all commodity contracts and different for each smart contract? EDIT: I just noticed that you defined volume as grams. Then the question becomes: aren't there commodities that are measured in other units, e.g. by volume instead of weight?
• Have you considered making payments in native tokens? Payments are made in fungible tokens that are created with the smart contract, which adds a lot of friction. In order to buy a contract, I would have to own these specific tokens first, and there is no way to pay with tokens in one smart contract for commodities in another deployment. Also, I don't see any mention of a token in your grant application.

[semuelle]

@MatteoPerona, could you also look at my notes about the tests? Ideally, the unit tests don't just cover the happy paths, and the e2e test failed in my case.

[MatteoPerona]

Hey @MatteoPerona, thanks for the delivery and sorry for the long wait. It took me a bit to understand the logic of the smart contract, as I'm not so familiar with commodities. Everything looks good so far, I just have a few questions about the functionality in general.

Hey @semuelle, thank you for the great feedback and taking the time to understand my work. Below I quoted all your questions and did my best to give an informative response. At the end of this comment, I left a short conclusion where I discuss what I think makes sense to change now, vs what I would leave for later. Let me know what you think makes sense.

Since only the buyer can finalize, how do you ensure that the seller actually receives the total? Are you planning any kind of (off-chain) dispute mechanism?

For future iterations, the idea was to implement a sort of on-chain trial system that would decide the fate of the locked balance. I thought this was out of scope for this iteration of the project. Refer to the last point in the future plans section in the proposal.

Aren't there commodities that are measured in other units, e.g. by volume instead of weight?

Yes, I realized that weight made more sense than volume through development, so I changed the type but left the variable name. This was an oversight because I had been using the term volume so much throughout the rest of the project. I'll amend that.

Have you considered making payments in native tokens? Payments are made in fungible tokens that are created with the smart contract, which adds a lot of friction. In order to buy a contract, I would have to own these specific tokens first, and there is no way to pay with tokens in one smart contract for commodities in another deployment. Also, I don't see any mention of a token in your grant application.

Yes, I originally tried to implement payments with native tokens, but, after lots of trial and error and speaking with an Ink! team member, I decided that a native token works better for the purposes of this contract. I wanted the contract to be deployable to any Substrate based chain, and that seems to currently be impossible while using the native token for transactions since I would have to write chain extensions or depend on that infrastructure being set up for each blockchain. I want people to be able to deploy this anywhere and change it for the better; I think it's more pliable in its current state. I agree, however, that there is a glaring flaw if one deployed another instance of the contract. Perhaps, the best solution would be to implement transaction using smart contract tokens. In this way, if a developer only has to deploy a compatible token along with the ssal smart contract in order to be able to use it.

Could you also look at my notes about the tests? Ideally, the unit tests don't just cover the happy paths, and the e2e test failed in my case.

I looked through your notes and I'm not sure what went wrong when you were running the tests, but I will try to replicate the error and fix it. Additionally I wrote functionality to test unhappy paths in each unit test, but I think I should have separated them into their own tests for more clarity. Also, I've since thought of some cases that need to be tested.

Concluding Thoughts

I think going forward the best plan of action is to immediately change every mention of volume to weight in the code, docs, and article. Also, I will revise the tests, separating happy and unhappy paths and fixing the e2e test error. As for dispute resolution and the token functionality / using native token, I think those would work as a great second iteration to the project. What do you think of this plan? Should I change anything else before the next review?

[semuelle]

Hey @MatteoPerona, thanks for the thorough reply.

This all sounds very reasonable. The token isn't mentioned in the agreement, so it's really up to you. The tests should be as thorough as possible for the sake of your users.
Given the size of the grant, I didn't expect you to implement a dispute resolution mechanism. These are just questions that naturally come up when reviewing smart contracts.

Regarding tokens, yes, using the same token for all smart contracts would make sense and it would probably make it easier to later switch to a native token. I would suggest to implement that right away, but it also depends on what the roadmap for the project looks like beyond the grant. If you were planning to use the smart contracts as they are, feel free to leave it.

[semuelle]

pinging @MatteoPerona

[MatteoPerona]

Hey @semuelle,

Apologies for the late reply, I'm heading into a very busy patch.

In the grant proposal I don't think I included dispute resolution as a deliverable, but I can do my best to integrate some basic form of decentralized voting in the coming month. I will be very busy until March 15th though, so my next PR might not come until then. As for the tokens, I will leave them as is for the time being.

In summary, I'll change the volume variable to weight everywhere it is mentioned, I will revise the tests making them clearer and adding any necessary cases, and I will implement a basic dispute resolution mechanism before the next PR.

Does that sound like a good plan to you?

Thanks for your continued feedback.

[semuelle]

Don't worry about the dispute resolution, as it's not part of the agreement. If you can look into the tests and possibly the handling of units, I'd be content.

[keeganquigley]

pinging @MatteoPerona

[MatteoPerona]

Hi @keeganquigley thanks for pinging. Those last few changes should be completed by Monday. Apologies for the drawn out schedule, I'm really overextended at the moment.

[MatteoPerona]

Hey there,

I just finished making changes. Should I create a new PR? Just not sure because the changes did not affect any of the functionality: just semantics or test related changes.

Recap:
I changed the volume variable to weight everywhere it is mentioned, and revised both unit and e2e tests. If there is an error message when running e2e tests that should be expected as long as it ends with " ... ok", its from a fail case test. I'm not sure if its common practice to remove them, but I could not find a way to do so.

Thanks for your patience. Let me know what the next steps are.

[semuelle]

Should I create a new PR?

Hey @MatteoPerona. Since this PR is still open, I don't think it's necessary to open another one. I will review the changes in the coming days. Did you document them anywhere?

[MatteoPerona]

Hi @semuelle,

I didn't document more than my commits, but all of my changes are as we discussed:

"change every mention of volume to weight in the code, docs, and article. Also, I will revise the tests, separating happy and unhappy paths and fixing the e2e test error."

The one caveat was that the e2e error was an expected case for an unhappy path.

If it helps here's a list of the changes:

1. Changed all mentions of volume to weight in the lib.rs, README, and the article.
2. Separated unhappy paths from happy paths in unit tests.
3. Revised e2e tests and separated unhappy paths.

[MatteoPerona]

Pinging @semuelle

[semuelle]

Sorry, @MatteoPerona, your milestone has been accepted, see my evaluation notes here.

[github-actions]

🪙 Please fill out the invoice form in order to initiate the payment process. Thank you!

[github-actions]

We noticed that this is the last milestone of your project. Congratulations on completing your grant! 🎊

So, where to from here? First of all, you should join our Grants Community chat, if you haven't already, so we can stay in touch.
If you are looking for continuative support for your project, there are quite a few options. The main goal of the W3F grants program is to support research as well as early-stage technical projects. If your project still falls under one of those categories, you might want to apply for a follow-up grant. However, depending on your goals and project status, there are other support programs in our ecosystem that might be better suited as the next step. For example, projects with a Business Case/Token should look into the Substrate Builders Program or VC Funding and Common Good projects have a good chance of receiving Treasury Funding. If you are looking for guidance, the team at https://substrate.io/ecosystem/square-one/ has compiled a list of ecosystem support sources and are happy to help you navigate it.

For a more comprehensive list, see our Alternative Funding page. Let us know if you have any questions regarding the above. We are more than happy to point you to additional resources and help you determine the best course of action.
Lastly, we hope your W3F grant was a success and we want to thank you for being part of the journey!