ALL SMART CONTRACTS ARE DEPLOYED IN THE PANGOLIN TEST NETWORK OF DARWINIA
ALL TOKENS ARE MINTED IN THE TEST NETWORK PANGOLIN AND HAVE ZERO, 0, NONE ECONOMIC VALUE WHATSOEVER
THESE ARE ONLY TESTING TOOLS AND SMART CONTRACTS
Our project contains
a) A Backend part
b) A Frontend part
All deployed smart contracts have the same administrator account address
Problem: For any development in an EVM environment (especially inside a parachain EVM) starts with some basic infrastruture needed Only once such an infrastructure exists a developer can start building innovative products on top of it
Solution: We have developped:
i) An Oracle Dapp. Collects and publishes prices for any tokens that show on coingecko website.
ii) A Minter Dapp. All tokens tracked by the oracle sc are minted to ERC20 tokens
iii) A Dex Dapp. Collects liquidity of ERC20 tokens minted by Minter.
Mints a stable coin. Allows any account to use the faucet to get some stable tokens which he can then swap for any of the ERC20 tokens
With an Oracle smart contract to broadcast prices, a Minter smart contract to mint ERC20 tokens and a Dex smart contract, anyone can build on top of that his/her project. Anyone can deploy any of these smart contracts.
Backend contains two parts Oracle and Minter We have deployed an Oracle smart contract We are running a webserver. Anyone can run a similar webserver by typing $node server.js here https://github.com/Entity54/DarwiniaHackathon/tree/main/Pangolin_ntt54_Oracle_backend/ntt54_Oracle_webserver/server The webserver at initialization offers a basic front end and it reads basic information about available token data offered by coingecko api Webserver front end allows to approve another account address as price reporter so it can update prices in the oracle smart contract Automatically we have approved this address 0x563FD94f1A141a2289A5746b7A6f0bE9fB27daf0 as price reporter. The admin chooses the list of tokens from coingecko that wants the smart contract to store prices There are some predetermined lists and in our example we use the custom list The custom list contains 114 tokens (the top 100 tokens by market cap as seen on coingecko page, excluding stable coins and adding most polkadot and kusama coins available at time of deployment) It needs to be emphasized that the admin can add further tokens or remove existing ones
The second part of our backend and scrolling down from the Oracle (on the webpage as shown on the video) we can see that the admin can click and mint any tokens being tracked by the oracle smart contract that have a default 0 address, Tokens are now minted to ERC20 tokens with a total supply equal to the circulating supply as published at coingecko website (if there is no reported cicrculating supply, we use the total supply and if this is not reported either we mint a large number of tokens) The admin of Minter can approve any account address to withdraw any and all liquidity. The admin of Minter is also the admin of all ERC20 tokens minted so the admin can mint , burn ERC20 tokens and also change admin of an ERC20 to another address
The user must have chrome Metamask extension installed and logged in with a prefunded with PRING account to be able to pay for any transactions Our front end has three pages
Token prices retrieved from the oracle smart contract are shown
The holdings and usd value for each of the 114 tokens we have minted, and the total portoflio value of the account chosen. This updates once every 20 blocks
The user can also transfer any of his ERC20 tokens or PRING tokens to his friends
This is where the user can use the faucet to get some stable coins in his metamask Limit is $100,000 for the lifetime of any account
Now the user can choose to swap his stable for any token he chooses from the drop down list, or if he has any tokens swap these back to stable at Oracle determined prices
The Oracle webserver has few points of attack that could be the base for further expansion and improvement. Dex can also be improved much further
Firstly, the machine running the webserver and feeding prices to the Oracle smart contract can be attacked.
One way of addressing this is the following
Visualise 10000 individual having their account address approved by the admin. Then each one can run the webserver from his own pc.
The oracle smart contract will have to be upgraded to get an aggregate feed from the 10,000 individual servers and also think of tokenomics and proof of staking by price reporters so that it becomes both of economic interest to the price reporters, self sufficient project and some tokenonimcs with regards to fees paid by price consumers
Now an attack will have to affect more than 51% of price reporters to the oracle smart contract
Secondly, currently the webserver grabs prices from coingecko and feeds the oracle smart contract.
An upgrade to that would be to retrieve prices from several CEXs such as MEXC,Binance,Huobi etc. and even Dexes deployed in the parchain EVM or using XCM DEXs deployed in other parachains
An aggregate token price would be sent from each price reporter
Now an attack to any price provider centralised or decentralised, would be filtered out first at the price reporter level, running the webserver on his pc
Thirdly, currently the admin of all smart contracts is the same address.
There is the functionality in each smart contract to change the admin of each smart contract and each minted ERC20 tokens.
For our testing purposes this is fine but in reality it would be preferable if after deployment the admin which is currently one address, changes to a DAO address.
Some Dex imporvements could be applying fees e.g. 0.30% and even artificial slippage.
Also instead of the simple formula used, one could use the x * y = k formula but this complicates unnecessarily our testing tools (e.g. write a smart contract bot that continously interacts with AMMs for all tokens, looking at Oracle smart contract prices to bring the AMMs pricing in-line with this) unless one's project is to build around that smart contract architectural design,
We have spent endless sleepless nights developing these tools.
Can these be improved? Of course, above are just a few of our thoughts.
For the time being these offer an infrastucture to our team (and hopefully to many more teams) to use these and develop our projects while having a fairly realistic environment in the test network!!!