DAOsign

[Burmenska]

Project Abstract

Please replace these instructions with a brief description of your project summarising key points (1-2 paragraphs).

If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable.

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 (project_name.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. Could you sign our terms and conditions (see the message above)? Also, could you specify which open source license you are planning to use as well as integrate the default deliverables (0a., 0b., etc.) into the second milestone? Furthermore, it's not fully clear to me why you want to integrate the eip712 and eip2771 as ink! smart contracts. Could you add a more detailed explanation as well as potentially link to the existing standards? In most cases, it makes sense to adjust the standards rather than simply reusing them.

[semuelle]

pinging @Burmenska

[Burmenska]

Hello , thanks @semuelle for the ping. T&C are signed, I'll be back to you with the answers shortly.

[Burmenska]

@semuelle hello! the application was updated but there is some error in the CI/CD. can you please help me to resolve it?

[semuelle]

Hi @Burmenska. Thanks for the update. Don't worry about the CI, this is just for internal bookkeeping.

[semuelle]

Thanks again for the application, @Burmenska! I have a couple of comments/questions:

adaptation means that user data is converted to a binary bit

I don't understand this part, can you explain? A bit doesn't hold a lot of information. :)

• There is already a standard an an implementation of ERC721 in ink!: code, website. I would suggest reusing their implementation and removing this deliverable altogether.
• You can leave the license as 'TBD' for now, but please note that it would have to be one approved by OSI.
• Meta transactions require an off-chain relayer. Could you add this to the deliverables?
• Related: there is no Docker deliverable in your milestones. For testing purposes, especially when it includes a relayer, some kind of setup automation would be very helpful.
• Can you be more specific in the specification of your deliverables? Specifications should be verifiable, so ideally for a smart contract it should list its functions or functionality.
• What does 'Application Private Key Management' mean?
• Wouldn't it make sense to split the EIP2771 work into a separate milestone? The rest of the platform works without it, correct? I'm mainly asking because I think this work would be interesting for many others in the ink!/Substrate ecosystem, and having a separate milestone would help

[Burmenska]

hello @semuelle , thanks for your comments, happy to answer, see below:

There is already a standard an an implementation of ERC721 in ink!: code, website. I would suggest reusing their implementation and removing this deliverable altogether.

Thanks for the link, will update the deliverables.

You can leave the license as 'TBD' for now, but please note that it would have to be one approved by OSI.
Checking with the team, will update an application shortly.

Meta transactions require an off-chain relayer. Could you add this to the deliverables?
We assumed that meta transactions are done on-chain according to the standard. If this assumption is wrong, please share the link to the documentation where we can check the details of it and I'll be happy to update the deliverables.

Related: there is no Docker deliverable in your milestones. For testing purposes, especially when it includes a relayer, some kind of setup automation would be very helpful.
Docker image will be provided: for E2E tests for sure, for smart contracts we can discuss further but if there will be a need, no issue with providing it as well.

Can you be more specific in the specification of your deliverables? Specifications should be verifiable, so ideally for a smart contract it should list its functions or functionality.
We will add interfaces to the application, would it be enough ?

What does 'Application Private Key Management' mean?
!ink logic does not include storing private keys, but they will be stored on the backend side. This part of the 2nd milestone includes development of private keys storing and management on the backend side, should I include this information into the application?

Wouldn't it make sense to split the EIP2771 work into a separate milestone? The rest of the platform works without it, correct? I'm mainly asking because I think this work would be interesting for many others in the ink!/Substrate ecosystem, and having a separate milestone would help

From the development standpoint, within the RUST workspace we plann to include EIP2771 as a separate subrepository . From the reporting standpoint, it is included into a bigger milestone but if you believe, that it makes sense to separate it, let me know pls. It should not impact neither scope nor duration of the project.

[semuelle]

We assumed that meta transactions are done on-chain according to the standard. If this assumption is wrong, please share the link to the documentation where we can check the details of it and I'll be happy to update the deliverables.

My understanding of ERC2771 is that a relayer accepts and forwards messages off-chain. It's named [Gas Relay](https://eips.ethereum.org/EIPS/eip-2771) in the spec. Are we talking about different things?

We will add interfaces to the application, would it be enough ?

Yes, interfaces are ideal.

!ink logic does not include storing private keys, but they will be stored on the backend side. This part of the 2nd milestone includes development of private keys storing and management on the backend side, should I include this information into the application?

There should be some kind of specification for each deliverable that we can refer to during the evaluation, so we can verify that everything was delivered as expected. I don't know what private keys you are planning to store, so I cannot comment on what needs to be included in the application and if.

From the development standpoint, within the RUST workspace we plann to include EIP2771 as a separate subrepository . From the reporting standpoint, it is included into a bigger milestone but if you believe, that it makes sense to separate it, let me know pls. It should not impact neither scope nor duration of the project.

That works.

Thanks for the link, will update the deliverables.

Thanks. Please ping me here when you are done updating, I'll have another look then.

[semuelle]

pinging @Burmenska

[Noc2]

Thanks for the update. But to already mention it. Please specify the license already at this stage. You can always amend it later. "most likely there will be Apache 2.0" could mean anything, even a non-open-source license, which is mandatory for this grants program.

[Burmenska]

@Noc2 thanks for the comment, already updated the License details. It will be Apache 2.0

Also @semuelle as per your request regarding interfaces, I added smart contract examples on Solidity along with the documentation, please let me know if it works for you.

thanks!

[ramilexe]

Hi @semuelle

CTO of DAOsign here. Let me step back and start from the beginning.

DAOsign propose to store Agreements Proofs on Polkadot chain using Ink! smart contracts. And provide methods to verify signature on-chain.

There are two types of users in DAOsign:

• Creator of agreement
• Signer

Proofs are implemented in EIP-712 standard and signed using user’s EVM private key (using Metamask for example). We are supporting this standard in Ink! smart contract to be able to verify signature.

Creator can select option where to store proofs: only on IPFS or also on Polkadot. If they select Polkadot then Creator needs to pay some fee that will be used for transaction gas fee. For that, we are also implementing EIP-2771 standard to allow Agreement Signers gas-free delegation to publish proof on-chain.

Here is a sequence diagram describing our process:

We are working on Smart Contract implementation for EVM-based chains, and you can take a look at the code here. This code is still in progress, but it gives some understanding of our approach. Documentation is also available.

Answering to your question:

My understanding of ERC2771 is that a relayer accepts and forwards messages off-chain. It's named Gas Relay in the spec. Are we talking about different things?

ERC2771 gives as ability to execute delegated call from Signer without making them to pay gas fee. Does it make sense?

Let me know if you have any questions or concerns,
Ramil

[ramilexe]

Here is technical design and documentation for EVM-based chain integration:
EVM Blockchain Integration - DAOSign - Confluence.pdf
Just for reference. We are going to support the same interfaces/approaches on Polkadot.

[semuelle]

Thanks for the updates, @Burmenska and @ramilexe. Some follow-up questions:

[semuelle]

0d is usually a Dockerfile or some other setup automation tool to help us and others test the project. Ideally, this would run a local node, deploy and instantiate the contracts or run unit tests on the smart contracts.

[ramilexe]

@semuelle @keeganquigley added docker step as 0d

[keeganquigley]

Thanks @ramilexe typically this is required for all milestones, as I would think the local contract node would be needed for M2 as well. But an npm/yarn package should suffice if its easy to get up and running.

[ramilexe]

@keeganquigley I don't see how docker could help with npm/yarn modules. It will be used docker from previous milestone to spin up node with smart contract

[keeganquigley]

@ramilexe Docker just helps for quickly spinning up a contracts-node to run the smart contract. So no worries, that's fine if it will be the same as the previous milestone.

[takahser]

@ramilexe I just realised that M2 still doesn't contain the Docker deliverable. Could you please add it? As already mentioned by @keeganquigley it's sufficient if it's the same as in M1, but I think it'd make it easier to evaluate it you'd deliver.

[ramilexe]

@takahser @keeganquigley I thought we agreed we don't need docker for M2 because it will contain Javascript library and frontend that usually delivered as a npm module, not docker container

[takahser]

@ramilexe I think the idea was to use the same docker config file(s) as in M1 to test the integration with the js library. You can add a note that indicates that. Alternatively, you can add a note to the SDK indicating that it will be compatible with the docker deliverable from M1.

[ramilexe]

Added docker to m2. Is it ok?

[dsm-w3f]

@ramilexe thank you for the answer. Look a reasonable approach to me. I think in the future we could have a solution that is more Polkadot native than a converted one from Ethereum. I'm happy to go forward with it.

[Noc2]

Sorry for the delay here. I'm also happy to go ahead with the project.

[keeganquigley]

Thanks @Burmenska for the changes and for your thorough answers. The application looks a lot better to me now than last time I looked at it, and I'm willing to go forward with it as well. LGTM.

[nikw3f]

The project would be a plus to polkadot ecosystem. Its good from my side.

[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! 🚀

[Burmenska]

@semuelle @Noc2 @keeganquigley @dsm-w3f @nikw3f , great news, we greatly appreciate the level of detail and attention you paid to our application, as well as all your questions. We are thrilled about receiving the grant and are super enthusiastic about this partnership.we will review the requirements to the delivery process together @ramilexe and I'll be back to you in case of any questions.

Thanks!

[semuelle]

Don't hesitate to contact us if you have any questions, @Burmenska.

[keeganquigley]

Hi @Burmenska are you able to provide an update on M1?

[Burmenska]

hello @keeganquigley, thanks for your patience. @ramilexe , DAOsign CTO already has everything in place and is preparing a PR. I will update you once the pull request is committed, it should happen in the nearest days.

[ramilexe]

Hi @keeganquigley
Pull request for Milestone 1 delivery has been created: w3f/Grant-Milestone-Delivery#1135

[keeganquigley]

Hi @Burmenska @ramilexe how is milestone 2 coming along? Are you able to provide an update?

[keeganquigley]

Hi @Burmenska @ramilexe are you still working on this grant? As I noticed there haven't been any commits to the repo in quite some time. Thanks for any info you can provide.

[Burmenska]

Hello @keeganquigley , I hope you’re doing well. I’m really sorry for the delivery delays and for the inconvenience it caused you. I haven’t been part of the DAOsign team since April and unfortunately can’t provide updates on this matter. However, let me pass your request to @ramilexe and another colleague who is currently responsible for grants delivery and I'll let you know once I'll have some update.

If there's anything else, I can help with, please let me know.

Thanks and have a great day!

[keeganquigley]

Thanks for the update @Burmenska much appreciated. @ramilexe let me know if you can confirm.

[ramilexe]

Hi @keeganquigley
We are finishing testing and will be ready to present our work in a few days

[keeganquigley]

Hi @Burmenska @ramilexe I think we still haven't received a delivery for this yet, correct?

[keeganquigley]

Hi @ramilexe are you still planning to submit a delivery soon? Otherwise we would likely cancel the grant due to inactivity.

[Burmenska]

@keeganquigley , sorry, as I previously mentioned , I'm not a part of DAOsign team since April 2024. Still, let me pass your request to the team, perhaps @ramilexe just missed it.
Thank you for the patience and understanding !

[eugeneBskyy]

@keeganquigley Hi Keegan,

We sincerely apologize for the delay and the lack of updates. Unfortunately, we encountered some unforeseen resource issues which affected our timeline. Additionally, we had to implement some technical changes that we didn't initially anticipate.
However, we want to assure you that we are actively working on finalizing both Milestone 2 and Milestone 3, and we aim to submit them within 2 weeks.

We truly appreciate your patience and understanding, and we are committed to delivering quality work.

Thank you once again for your continued support, and we will keep you posted with further updates. Please tag me or @TetianaRiabova for any next messages.

[keeganquigley]

Sounds good @eugeneBskyy thanks kindly for the update. Could you give a few more details about the technical changes? Will this change any of the deliverables?

Minor changes are no big deal, but please note that any major changes would require an amendment, if it will change any of the end deliverables. Thanks!

[keeganquigley]

Hi @eugeneBskyy any updates?

[eugeneBskyy]

Hi @keeganquigley

Thanks for your patience. The technical changes we implemented are not related to the core functionality that was outlined in the grant. The main challenges we faced were around integration with the app, specifically around generating the correct payload. As a result, we made adjustments to the integration side of things to ensure everything works smoothly.

In terms of updates, we are currently preparing the pull request, and the code is in its final review phase. We are targeting to submit the PR for both Milestones 2 and 3 by Thursday.

Thank you again for your understanding, and we'll keep you posted.

Best regards,
@eugeneBskyy

[ramilexe]

Hi @keeganquigley
here is link to PR: w3f/Grant-Milestone-Delivery#1216

[ramilexe]

Hi @keeganquigley
Here is link to Milestone 3 delivery PR: w3f/Grant-Milestone-Delivery#1227