The project's overall scope comprises developing a tunnels/bridge platform, where the users will be able to swap their tokens from the ETH chain to Binance Chain and vice versa. There will be a wrapped token created for DDK coin on the ETH chain and the Binance Chain. The wrapped token will be able to peg the value of the DDK coin.
This wrapped token can be listed and use in the decentralized exchange and DEFI apps of the ETH chain and the Binance Chain. The swapping will be possible in between the EDDK and BDDK tokens. The user will be able to connect their MetaMask, TrustWallet, and CoinBox Wallet to the platform. The platform provides the functionality to migrate tokens from Binance Smart chain to Ethereum and vice versa.
Users will be able to select the token they want to convert and its amount. Next, users will be able to select the token to which they wish to convert; once the token is selected, users will view the amount of new token they will receive. Once the transfer function is initiated with the miner fees on the particular chain, the tokens will be converted and deposited in the user wallet.
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.
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
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.
CoinBox Finance aims to develop a platform that allows users to transfer their DDK tokens from the ETH network to Binance Chain and vice versa.
The Bridge feature has made the process of moving coins with various chains easy, safe, and comfortable without relying on middlemen.
This makes it easy for the users to exchange their ERC20 and BEP20 tokens without leaving their wallets. This also allows users to organize their assets to take advantage of volatile prices.
