Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dotflow #1657

Merged
merged 7 commits into from
May 31, 2023
Merged

Dotflow #1657

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
d5db92d
Dotflow
Szegoo Apr 5, 2023
c94e687
Update Dotflow.md
Szegoo Apr 6, 2023
e87f50d
Describe milestones better
Szegoo Apr 10, 2023
9fcc8b7
Update Dotflow.md
Szegoo Apr 27, 2023
7febd38
Remove accidental empty lines
Szegoo Apr 27, 2023
7d88a4e
Update Dotflow.md
Szegoo May 22, 2023
42b0310
Update Dotflow.md
Szegoo May 26, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
179 changes: 179 additions & 0 deletions applications/Dotflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,179 @@
# Dotflow

- **Team Name:** Sergej Sakac & Oliver Lim
- **Payment Address:** 0x1e86CD18E4443B5f57b0133077954Cd84896964d (USDC)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2

## Project Overview :page_facing_up:

### Overview

#### Problem
We can most certainly agree that the future is multi-chain. As such, it is not uncommon for users to hold multiple accounts across various chains for reasons such as distinct address formats and security benefits. However, this practice presents a challenge in managing multiple addresses. Adding to the complexity is the need to verify the address of the intended recipient, as it may have changed over time.

In summary, there are two key challenges to address: the management of multiple addresses and making sure the addresses of the recepients did not change in the meantime.

To mitigate these challenges, we aim to simplify the user experience by abstracting away the complexity of address management.

### Project Details

Our project will comprise of two smart contracts coded in ink!, and a React.js-based user interface.

The first contract will store users' address-related data in an entity called `Identity`. Each user will have their own `Identity`, which will contain their addresses across different chains. The Identity creators will be responsible for updating their addresses if any changes occur. Every Identity will be assigned a unique `IdentityNo`, which will serve a crucial purpose in the second contract.

Additionally, this contract will feature a function that, based on input arguments, will return the appropriate destination address for token transfers. This function will mainly be used by the user interface.

The second contract will be an address book that enables users to store the `IdentityNos` of the people they are most frequently engaged with . Each user will have the option to create their own address book, where they can add a nickname to each identity to differentiate them easily.

The UI we are going to build will serve the purpose of interacting with both of our contracts. Users will be able to create an identity and customize the addresses of their identity. Using the UI users will also be able to create their address book and customize it. The most important functionality the UI will provide will be routing.
When a user wants to transfer some tokens to an identity the user will only have to worry about the token, origin and destination chain and the identity they want to send the token to. Based on all of this the UI will query the first contract and based on that create a transaction that will route the tokens to the proper address.

In case the origin and destination chain are not the same, the UI will create an XCM message that will route the tokens to the proper blockchain.

Our ink! smart contracts will be deployed on the Astar network.

### UI Design
The UI will consist of three main parts:

- My Identity page
- Transfer page
- Address book page

#### My Identity page
![My Identity page](https://i.postimg.cc/288CDys6/1-1-dashboard-1.png)

The user will be able to create his own identity and provide the addresses that he owns on different chains.

![Add Address](https://i.postimg.cc/jdKdPQS5/1-1-create-identity.png)

In case some of the addresses the user owns change over time he will be able to edit them.

![Edit Address](https://i.postimg.cc/G2w1rdB2/1-1-create-identity-1.png)

#### Transfer page
[![2-1-transfer-1.png](https://i.postimg.cc/Cx9ZCHpB/2-1-transfer-1.png)](https://postimg.cc/75MYwz6w)

Ther user will be able to transfer tokens to an identity by specifying the origin chain, destionation chain, and the receiver's `identityNo`.

#### Address Book page
![Address book page](https://i.postimg.cc/QtXyT9kK/3-1-Address-book.png)

The user will be able to add identities to his own address book. The identities will be added by providing the `identityNo` and some nickname for the identity.
Also by clicking on the transfer icon on one of the identities the user will be redirected to the transfer page where the `identityNo` will be automatically filled out.

![Add identity](https://i.postimg.cc/TwzSg9j3/3-1-Address-book-2.png)

### Ecosystem Fit

This project fits perfectly with the Polkadot ecosystem because it has everything we need to make it work. Polkadot is a multi-chain network, so a lot of users have different addresses on different chains for the same reasons we mentioned earlier. That's why the problems we talked about are important in this ecosystem.

XCM is going to be a core component of our project since it'll help us transfer tokens between the parachains and the relay chain.

#### Target Audience
Our target audience is people who deal with sending assets frequently over the Polkadot network.

## Team :busts_in_silhouette:

### Team members

- Sergej Sakac [Szegoo](https://github.com/Szegoo)
- Oliver Lim [cuteolaf](https://github.com/cuteolaf)

### Contact

- **Contact Name:** Sergej Sakac
- **Contact Email:** sakacszergej@gmail.com
- **Website:** https://github.com/Szegoo

### Legal Structure
- **Registered Address:** Kanalska 7 Novi Sad Serbia
- **Registered Legal Entity:** MASTER UNION LLC.

### Team's experience

#### [Sergej Sakac](https://github.com/Szegoo)
- More than three years of programming experience
- Active contributor to [Substrate](https://github.com/paritytech/substrate/pulls?q=is%3Apr+author%3ASzegoo)
- Member of the [fellowship](https://github.com/polkadot-fellows/seeding/pull/36)
- Contributor to [rmrk-pallets](https://github.com/rmrk-team/rmrk-substrate/pulls?q=is%3Apr+is%3Aclosed+author%3ASzegoo)

#### [Oliver Lim](https://github.com/cuteolaf)
- Full stack blockchain developer with 5+ years of experience
- Quick learner and active contributor to open source projects
- [Fair Squares](https://github.com/fair-squares/fair-squares)
- [Imbue Network](https://github.com/imbuenetwork)
- [Anagolay Network](https://gitlab.com/anagolay/anagolay)
- ...

### Team Code Repos

We will be working on two separate repos, one for the UI and the other for the ink! contracts.

- https://github.com/TheDotflow/dotflow-ui
- https://github.com/TheDotflow/dotflow-ink

Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

- https://github.com/Szegoo
- https://github.com/cuteolaf

### Team LinkedIn Profiles (if available)

- http://linkedin.com/in/sergej-sakac-334a47252
- https://www.linkedin.com/in/oliver-lim-2215a8235/

## Development Roadmap :nut_and_bolt:

### Overview

- **Total Estimated Duration:** 2,5 months
- **Full-Time Equivalent (FTE):** 1.5 FTE
- **Total Costs:** 19,000 USD

### Milestone 1 Example — Basic functionality

- **Estimated duration:** 1 month
- **FTE:** 1,5
- **Costs:** 8,000

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| **0a.** | License | MIT |
| **0b.** | Documentation | Ink! contracts and the UI code will be well documented and open for everybody to take a look. The UI will be simple and intuitive to use. |
| **0c.** | Testing and Testing Guide | The Identity ink! contract will be well tested with unit and integration tests. |
| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milesone. |
| 1. | Identity Contract | We will write the code for the Identity contract that was explained above. This includes functionality for creating an identity, adding addresses to an identity, updating the addresses of an identity. We will also implement the routing function that will return the proper destination address based on input arguments. |
| 2. | My Identity page | We will make a UI that will allow users to interact with the Identity Contract. Users will be able to access all of the functionality from the Identity Contract by using this UI |


### Milestone 2 Example — Additional features

- **Estimated Duration:** 1,5 month
- **FTE:** 1,5
- **Costs:** 11,000

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| **0a.** | License | MIT |
| **0b.** | Documentation | Both contracts and the website code will be well documented and open for everybody to check. The UI will have a simple UI that will be intuitive to use. |
| **0c.** | Testing and Testing Guide | The Address Book ink! contract will be well tested with unit and integration tests before being deployed to the Astar network. The functionality for generating XCM messages will very well tested to make sure the tokens are always transfered to the proper destination. |
| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milesone. |
| 0e. | Article | We will publish a Medium article that explains the details of our project. |
| 1. | Address Book Contract | We will write the code for the address book contract. This will contain the functionality for creating an address book, adding and modifying addresses. |
| 2. | Routing functionality. | We will write the logic for constructing XCM messages that will route the tokens to the proper address. In case the destination chain is same as the origin there will just be a simple transaction. The code for this will be stored on the frontend.
| 3. | Address Book page | We will make a UI that will allow users to interact with the Address Book Contract. Users will be able to access all of the functionality from the Address Book contract by using this UI |
| 4. | Transfer page | We will make a UI that will allow users to send tokens by setting the destination to some `IdentityId`. The UI will abstract addresses away and take care of the routing. |


## Future Plans

Our future plan is to expand our core functionality and add more features so that the tokens can be routed based on some different criteria. Some example of these ideas are:

- Route tokens based on the amount, sender and/or the token itself
- Split the transferred amount to multiple addresses

An exciting feature we would like to build in the future is enable token transfers between blockchains that are not part of the Polkadot network(e.g. Polkadot<->Ethereum).

## Additional Information :heavy_plus_sign:

**How did you hear about the Grants Program?** GitHub