Grant Application: Roloi - XCM Payment Automation

[pcorrado-np]

Project Abstract

Our project enables the automation of ink! smart contract transactions in a recurring way. Using XCM, we can schedule transactions on Shiden (Astar) with the assistance of Turing's (OAK) functionalities.

We will deliver a generic project as a public good that teams can use to automate cross-chain transactions:

• A Typescript Next.js UI with abstractions that simplify the most tricky parts for developers such as Accounts connection, Proxy Accounts, and XCM messages creation.
• An ink! Smart Contract that handles token transfers between Shiden accounts.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (roloi-xcm-payment-automation.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks for the application. Here is some quick feedback:

• the image linked in your application currently doesn't work for me.
• Usually, for UI-focused milestones, we ask teams to already provide some mock-ups or initial designs
• I would recommend mostly focusing on the software that you need to develop as part of the project and not so much any specific parachain or token. For us, it's usually sufficient if we are able to test it on a local chain. We need to be as objective as possible when it comes to certain parachains.

[pcorrado-np]

Thanks for the application. Here is some quick feedback:

• the image linked in your application currently doesn't work for me.
• Usually, for UI-focused milestones, we ask teams to already provide some mock-ups or initial designs
• I would recommend mostly focusing on the software that you need to develop as part of the project and not so much any specific parachain or token. For us, it's usually sufficient if we are able to test it on a local chain. We need to be as objective as possible when it comes to certain parachains.

@Noc2 Thanks for the feedback!

We'll work on improving that and get back to you with our updated application.

Thanks!

[pcorrado-np]

Hi @Noc2! We updated our application:

• Fixed image
• Updated technical details section to better describe the current process
• Added a new "Our solution" section to describe our generic software solution
• Added a new "Wireframes" section to display our UI initial wireframes

Thanks again for your useful feedback!

[keeganquigley]

Hi @pcorrado-np thanks for the changes. Looks good and it's cool to see you partnering with Oak after your previous grant. Excited to more on-chain automation tools like this. I'm happy to go ahead with it. I will mark it as ready for review and ping the rest of the committee.

[Noc2]

Thanks for the very quick reply here and the update. I'm also happy to go ahead with it.

[pcorrado-np]

Hi @Noc2 @keeganquigley!
Thank you both for your quick feedback. We’ll stay tuned for any news.

[dsm-w3f]

@pcorrado-np thank you for the application. I think the scope of the grant interesting, however the price charged is very high. The wireframes presented has 5 pages and the price for develop them (M1) is almost 42k. Furthermore, M2 scope is to develop a smart contract, which probably you already have part of it developed in the previous grant or because of the kind of business NeoPower runs. Adding XCM to it should not be a big deal, and the price to do it is 28k. Could you consider going for a level 2 grant?

[pcorrado-np]

@pcorrado-np thank you for the application. I think the scope of the grant interesting, however the price charged is very high. The wireframes presented has 5 pages and the price for develop them (M1) is almost 42k. Furthermore, M2 scope is to develop a smart contract, which probably you already have part of it developed in the previous grant or because of the kind of business NeoPower runs. Adding XCM to it should not be a big deal, and the price to do it is 28k. Could you consider going for a level 2 grant?

Hello @dsm-w3f, thank you for taking the time to review our application.

We truly appreciate your feedback and understand your concern regarding the pricing.

Regarding Milestone 1, the main value of the proposal is about the Typescript logic, React hooks, and code encapsulation to ensure seamless integration with XCM in a generic way. Additionally, our proposal includes the development of the pages to create proxy accounts in a straight-forward way from both the developer and user perspective. What takes most of the estimation and effort in this milestone is the development of fully-typed reusable code for other teams.

Regarding Milestone 2, we don’t have an existing smart contract that does this. Our previous grant last year was about token streaming, and we don’t have any other smart contracts developed for Roloi so far. This development would be completely new to enable on-chain recurring transactions and integrate Kusama chains. This is important for our project because it requires robust testing since the canary DApp will interact with actual money.

From our experience while learning and teaching the Polkadot tech stack, we made sure that the estimations are accurate considering documentation, design, development, peer reviews, and testing.

We firmly believe that the tools developed through this grant will not only be valuable to our own product, to bring on-chain payment automation, but will also be beneficial to numerous other teams in the ecosystem. As part of our commitment to the community, we will actively share this in the various developers' communities we are engaged with, specifically in LATAM.

We appreciate the opportunity to apply for this grant, and we remain open to further discussions or clarifications if needed.

Thank you for your consideration, and we look forward to your response.

[dsm-w3f]

@pcorrado-np thank you for the answer. Although your argumentation is valid, I still think it does not justify the price charged. For this reason, I won't approve this application. The other members of the committee can have a different opinion on that.

[semuelle]

Since I haven't used OAK before, I'm not aware how recurring transactions are created and how much of this workflow can be automated away. It seems to me that the creation manual top-up would still be necessary. If I'm reading this correct, you want to build a smart contract to simplify managing recurring payments and a UI to simplify the setup. Is that correct?

[semuelle]

Can you provide another image that would show how the workflow would be with smart contract? Who would be paying the fees for the recurring transactions, and how? Would the smart contract manage the fees per user?

[pcorrado-np]

The workflow diagram generically shows the communication between an origin chain and OAK to enable recurring tasks, and the extrinsic can be any type of task. In our case, will be a smart contract transaction. Internally, the contract will validate the execution and trigger the configured transfer.

As for the fees, the idea is for users to top up the proxy accounts based on the defined recurrence settings.
On the UI side, we can simulate and estimate the fees of XCM and smart contract transactions to cover an approximate number of recurring repetitions. Then we’ll suggest to the user a concrete number of tokens to transfer to the proxy account to cover fees.
We’ll also use these estimation calculations on the UI to alert the user when they are running out of funds to pay the fees, so they can recharge the proxy account.

[pcorrado-np]

Since I haven't used OAK before, I'm not aware how recurring transactions are created and how much of this workflow can be automated away. It seems to me that the creation manual top-up would still be necessary. If I'm reading this correct, you want to build a smart contract to simplify managing recurring payments and a UI to simplify the setup. Is that correct?

Hi, @semuelle. Thank you so much for the review!

OAK recurrently triggers XCM transactions to the origin chain according to the previously received recurring settings. At the origin chain side, a proxy account takes the transaction that includes the encoded extrinsic to be executed (in this case, the extrinsic will be a smart contract transaction).

The creation and funding of proxy accounts will be integrated into the configuration of the recurring settings and will be simplified for the user with the UI.

And you are right:

• The Smart Contract will be in charge of storing and validating the users recurring settings and the execution of transfers.
• The main goal of the UI is to simplify the complexities of XCM and the OAK automation process, providing a great UI/UX for configuring recurring payments.

Thanks again for your time! We’ll stay tuned.

[semuelle]

Thanks for the replies, @pcorrado-np. A couple more questions:

• Could you integrate the wireframes directly into the application document? Otherwise they will soon be lost.
• The wireframes show a list of "incoming" payments. Incoming where? How does that work? I assumed the list would be showing the payments set up in the smart contract.
• Using a smart contract to communicate with a pallet seems a bit... redundant. Wouldn't this architecture be possible by directly interacting with the pallet?

[pcorrado-np]

Thanks for the replies, @pcorrado-np. A couple more questions:

• Could you integrate the wireframes directly into the application document? Otherwise they will soon be lost.
• The wireframes show a list of "incoming" payments. Incoming where? How does that work? I assumed the list would be showing the payments set up in the smart contract.
• Using a smart contract to communicate with a pallet seems a bit... redundant. Wouldn't this architecture be possible by directly interacting with the pallet?

Hi, @semuelle. Thanks again for your questions. We really appreciate the feedback to improve our application.

1. Thanks! We now updated the application document by adding the wireframe images.

2. Users will be able to connect their wallets to the UI. The incoming and outgoing payments refer to the incoming and outgoing transfers of the connected wallet. Not the entire contract history. This will be useful to have a usage example of a message that selects the payment flows of a given wallet.

3. We want to leverage ink!’s capabilities to enable on-chain validation rules for any business model other teams may have. This allows for more complex models other than just scheduling token transfers. For now, the smart contract will validate that the scheduled time matches with the executed time, and not just trust on a third party message.
   In the future, we also want to include the XCM communication with OAK through the contracts.

[semuelle]

Thanks for the quick reply, @pcorrado-np. I kind of agree with Diogo that it's a fairly high price. However, I would like for this project to become the basis for many other use cases and I trust that you make it as modular and generic as you say.

Perhaps you could add a tutorial for a second use case, e.g. how to modify the smart contract to allow token transfers.

[takahser]

@pcorrado-np thanks for the follow-up comments.

About our team, we are only describing our core team on the proposal. But for the FTE we are also considering designers, engineers and testers that work with us.

Keep in mind that our program is tailored to support software development efforts, but not design efforts. Also, if there are more software engineers on your team, you're supposed to list them as well. Quote from our README:

You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine for past activity and code quality.

Apart from that, I still believe it's too expensive.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[pcorrado-np]

I have read and hereby sign the Contributor License Agreement.

[pcorrado-np]

Hi @dsm-w3f @takahser @Noc2 @semuelle @keeganquigley,

Thank you all for your valuable feedback.

We've decided to lower the proposal's price by removing 1 FTE for each milestone.
NeoPower will cover the costs of the remaining resources.

We are looking forward to starting working on this project.

Thanks!

[takahser]

@pcorrado-np thanks for the update and lowering the price. However, I still believe a level 2 grant would be more appropriate.

Also, could you expand on the relationship between this proposal and the one you submitted to the OAK grants program?

[bsasbon-np]

@pcorrado-np thanks for the update and lowering the price. However, I still believe a level 2 grant would be more appropriate.

Also, could you expand on the relationship between this proposal and the one you submitted to the OAK grants program?

Hi @takahser, thank you for your feedback!

Thank you for pointing out that proposal. It had a smaller scope dedicated to OAK to reduce the complexity of the proxy account configuration. It didn't include XCM tooling.

We had no further responses from the team so we decided to close that old proposal and build a project that's focused on simplifying the development experience with XCM to be used with any parachain.

Thanks!

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[pcorrado-np]

To keep you informed about the status:

We are making significant progress with the Milestone 1.
We have detected a deviation from our original estimation and we are currently targeting to deliver Milestone 1 during the 2nd week of November.‌

We’ll keep track of the status through this PR.

Thank you for your support!

[keeganquigley]

Hi @pcorrado-np how is milestone 2 coming alone?

[pcorrado-np]

Hi @pcorrado-np how is milestone 2 coming alone?

Hi @keeganquigley,

It's taking longer than expected but we are making progress with the features. Sorry for the delay and not reporting that.

We hope to deliver the second milestone the week of February 5.

We'll keep you touched.

[pcorrado-np]

Hi @keeganquigley!

Status update:
We are close to finalizing the delivery of Milestone 2 in the upcoming days.
Everything is working as expected, and now wrapping up docs and article.

Thanks for your patience!

[keeganquigley]

Sounds good @pcorrado-np thanks for the update, much appreciated!