Dotflow
- Team Name: Sergej Sakac & Oliver Lim
- Payment Address: 0x1e86CD18E4443B5f57b0133077954Cd84896964d (USDC)
- Level: 2
Project Overview 📄​
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 two smart contracts coded in ink!, and a React.js-based user interface.
One of the ink! contracts will store the user's address-related data in an entity called Identity. Each user will have their own Identity, containing 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 address book contract and UI.
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. Each address book will be attached to a wallet so that when a user logs in with his wallet the UI and provides the IdentityKey the frontend will automatically be able to display the address book to the user.
The UI will serve the purpose of interacting with both smart 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 the 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 tokens to. Based on all of this the UI will query the identity 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. For the XCM transaction to work there has to be an existing XCM channel between the two blockchains.
Privacy​
Most of us don't want to share all of our addresses with the rest of the world. For that reason, we are including some privacy features that will keep all our addresses private. All of the addresses in the identity smart contract will be encrypted with a secret key.
Users will have multiple addresses each attached to a certain blockchain. AES 128-bit ciphers will be generated by the UI per each blockchain. These ciphers will only change if the user changes them when updating an address, otherwise, they will always be the same for the associated blockchain. Ciphers will be created when creating an identity or when adding a new blockchain address to the identity. These ciphers will be stored in a structured format so that the frontend code can associate each cipher with a blockchain. Ciphers will be stored locally in the following format:
-- We will call this data the 'Identity Key' --
blockchain_name_1:cipher_1;blockchain_name_2:cipher_2;...and so on
Each address will be encrypted with the associated cipher before it gets stored in the identity contract. This will ensure that no one has access to an identity's addresses simply by reading the contract's state.
To share an identity with someone the Identity Key will also be needed to be sent together with the IdentityNo. In case an identity doesn't want to expose all of their addresses to someone else, but only some of them, it is possible to send part of the Identity Key that contains the ciphers for the blockchain addresses he wants to share.
Of course, the user won't need to do this task manually, the UI will make this task very simple. The following section will show how this will work from the user's perspective.
In case we update some of our addresses but we want to restrict access to the users that previously were granted access to that address there will be an option to regenerate the cipher. This way everyone that had access to the old address won't have access to the new one.
UI Design​
The UI will consist of three main parts:
- My Identity page
- Transfer page
- Address book page
My Identity page​
The user will be able to create his own identity and provide the addresses he owns on to his identity.
In case some of the addresses the user owns change over time he will be able to edit them. Also, we can select the option to regenerate the cipher so that people that had access to the old address won't be able to access the new one.
When sharing their identity users will also be able to select which addresses will be available for the person they are sending their identity to. The user will have to copy his identityNo but also the identityKey which specifies which addresses are accessible for the user that receives this key.
Transfer page​
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​
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.
When adding an Identity to an address book the user will also be required to provide the Identity Key which will be used for decrypting the identity's addresses when sending tokens.
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 👥​
Team members​
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​
- More than three years of programming experience
- Active contributor to Substrate
- Member of the fellowship
- Contributor to rmrk-pallets
Oliver Lim​
- Full stack blockchain developer with 5+ years of experience
- Quick learner and active contributor to open source projects
Team Code Repos​
We will be working on two separate repos, one for the UI and the other for the ink! contracts.
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.
Team LinkedIn Profiles (if available)​
Development Roadmap 🔩​
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 using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Identity contract will provide a range of functions, including creating an identity, adding addresses that are mapped to specific blockchains, and updating these addresses as needed. The contract will automatically generate a unique identifier, referred to as identityNo, for each identity. To ensure maximum security, we will allow the identity creator to specify the accounts that are authorized to modify the identity's addresses. This will enable the creator to retain control of the identity even if they lose access to the account used to create it. |
| 2. | My Identity page | The My Identity page will be developed using React.js, providing users with a user-friendly interface to interact with the Identity contract. This will include the ability to create a new identity, add or remove addresses associated with an identity, and access and copy the unique identityNo to share with others. This UI will also generate the Identity Key for the user's identity and will update it every time he adds a new blockchain address. This Identity Key will be accessible for the identity creator when sharing his identity. The interface will be based on the mock design presented in the UI design section. |
Milestone 2 Example — Additional features​
- Estimated Duration: 1,5 month
- FTE: 1,5
- Costs: 11,000
| Number | Deliverable | Specification |
|---|---|---|
| 0a. | License | MIT |
| 0b. | Documentation | The contract 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. 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 | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book will enable users to create an address book and populate it with the identities they interact with most frequently. The identities will be added via their identityNo since our main goal is abstracting away addresses from the users. When adding an identity to an address book the Identity Key will also be needed. The address book will be stored on chain but the IdentityKey will be stored in local storage. The application will expect the user to provide the IdentityKey when using the app from a different device for the first time. |
| 2. | Routing functionality. | The code responsible for routing tokens to the correct destination will be incorporated into the frontend code written in TypeScript. This code will incorporate the necessary logic for constructing XCM messages to route tokens to the appropriate address. In cases where the destination chain is the same as the origin, a simple transaction will be executed. Because of possible race conditions where the identity owner is trying to update an address on a parachain while another user is trying to send funds to that identity on that parachain we introduce additional checks on the frontend. Before sending a transaction that will transfer the funds, the frontend will check whether there are any pending transactions happening that would change the address on the chain the user is transferring funds to. In case there is a pending transaction the user will get a warning and will be advised to wait for a moment and try sending the transaction again. |
| 3. | Address Book page | We will write the code for the Address Book UI using React.js. The UI will be based on the provided mock design that we displayed above in the UI design section. The UI will make it possible for users to create an address book and add identities to it. |
| 4. | Transfer page | We will create a user interface using React.js that will enable users to send tokens to a designated IdentityId. This UI will abstract away the complexity of addresses and leverage the Routing functionality described in this table(Section 2) to handle token routing. The UI design will be based on the mock design presented in the UI design section for optimal user experience. |
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 ➕​
How did you hear about the Grants Program? GitHub