Features

General Requirements

• A wrapped token will be created for the DDK coin on the ETH chain and the Binance Chain.

• The wrapped token will peg the value of the DDK coin

• The token will be listed in the decentralized exchange of the ETH chain and the Binance Chain for pairs of EDDK and BDDK.

Customer Modul

Connect Wallet

• The user will be able to connect any of the following wallets

  • Metamask

  • Binance Chain Wallet

  • Fortmatic

  • Trust Wallet

  • CoinBox Wallet

Tunnels

• Users will be able to convert tokens from Binance Smart chain to Ethereum and vice versa

  • Users will be able to select the token they want to convert

  • ■ EDDK

  • ■ BDDK

  • Users will be able to enter the amount of token they require to swap

  • The entered number of the token should be present in the user's wallet

  • On initiating the transfer function, the tokens will be deducted from the wallet, and swapped tokens will be added to the wallet

Technical Overview

Technical Architecture

The platform is designed to provide a secure and scalable platform to engage and interact with users. Considering these requirements, we have identified microservices-based architecture will be the ideal fit for the application. The reason for choosing this architecture is as follows:

• As there will be multiple components and modules that need not be coupled together and should be developed in parallel, microservice architecture can make this happen, and a single team can manage one service, thereby making development parallel and fast.

• When a new module wants to add to the existing system, it should be developed and deployed independently without affecting the existing application.

• Differents modules and services, such as wallet management, event management, etc. which need to work independently and will require different technology changes to make this happen.

• All the data will be abstracted, and a greater level of isolation can be obtained using this type of architecture.

The application will be based on the microservice architecture. All the connections will be interfaced by a Load Balancer which will be responsible for distributing the load across multiple instances based on the load on each service. There will be a firewall enabled in the Loadbalancer and thereby regulating the type of request coming into the servers.

Once the Load Balancer chooses an activity zone, the request will reach an API Gateway. API Gateway acts as a reverse proxy that helps in routing requests from clients and services. API Gateway also helps in choosing the service to redirect the requests to based on the service registry. Some of the other functionalities of API Gateways are requesting, throttling, authentication, etc. An Authentication Server is used for authenticating users in the application, using OAuth 2.0 authentication protocol, and JWT will be issued; this JWT will be used to authenticate the API calls coming into the system. After the authentication, the API Gateway will redirect the request to the service based on what actions need to be done. All the services will have a REST interface to which the internal routing of requests is done. The data persistence of each service is the responsibility of the service itself.

Certain actions cannot be done in real-time and need to be queued for future implementation. We will be using an AMQP based message queue to handle the asynchronous tasks and will also be used to share tasks or information between the services as well. The queue will be a pub-sub model, and services will publish to the queue and then subscribe from them; Apache Kafka can be a good example.

The static content, such as the frontend, will be served using a CDN (Content Delivery Network), and the files will be served to the network using a static file storage system. The main advantages of using a CDN are performance boost in delivering static content like HTML pages, images, videos, etc. Another major advantage is that it takes the overhead from the application server to serve these files, thereby enabling the servers to cater more API calls.

External components of the architecture are the Binance Node and Ethereum Node, which will host the Smart Contracts that host the functionality for the token conversion from one network to another by burning and minting the respective tokens.