Aria Smart Contract

We have been getting lots of questions lately around our smart Contract such as

- What blockchain is it on?
- What contract did you fork?
- How are the fees calculated?
- How will rewards be distributed?

and much more…

I am hoping to answer all these today in this write up and show some snipped of codes of our contract as well.

Alright lets start of with what blockchain. We chose Binance Smart Chain. One of the main reason is because of how much documentation there is on Solidity smart contracts and so many examples of working contracts. The other reason is the low fees on BSC, can’t beat cheap prices. Also Binance has established itself as a big player in the market so people will recognize it. Those were really the only reasons that went into our choice.

Why did we choose USDC as a payment? This was just because we like USDC, it has established itself in our humble opinion as the leading USD stable coin.

Now what contract did we fork?

The main contracts are from Roger Wu and this one from Jo-es They were the main contract for figuring out how to distribute rewards to all token holders. We had put in modification for paying out in USDC and the constraint regarding the minimum required to hold and time between pay outs which we set to 100,000 $ARIA token and 30 minutes.

What type of token are you? Reflection? Rebase?

I think this is a hard one to answer as it is Reflection in the sense that we take a transaction fee and distribute it to holder, the reward is in USDC. It is a Rebase token in the sense that the token will have a changing circulating supply which will have min and max boundaries of 1Billion and 100Billion. To make is easier I think we can just say reflection going forward.

Sell and Buy fees

Here are the main fees that will go in any buy order

uint256 public USDCRewardsFee = 5; // 5min - 10max
uint256 public liquidityFee = 2;   // 1min - 5max
uint256 public treasuryFee = 2;    // 1min - 5max
uint256 public marketingFee = 3;   // 1min - 5max
uint256 public totalConfigFees = USDCRewardsFee.add(liquidityFee).add(marketingFee).add(treasuryFee);

The configurable fees will have a limit of 15% total and you can see the set fee function will enforce it. Since we are putting all these limits in on our contract it is making a safer contract because the owner of the contract cannot change the fees to 100% which would be a nightmare for everyone.

uint256 public _maxTotalFee = 15;
uint256 public _minMintBurnFee = 0;
uint256 public _maxMintBurnFee = 3;
uint256 public _minUSDCRewardsFee = 5;
uint256 public _maxUSDCRewardsFee = 10;
uint256 public _minLiquidityTreasuryDevMarketingFee = 1;
uint256 public _maxLiquidityTreasuryDevMarketingFee = 5;
function setFees(uint256 reward, uint256 liq, uint256 treas, uint256 devMark) external onlyOwner {
uint256 tempTotalConfigFees = reward.add(liq).add(treas).add(devMark);
require(tempTotalConfigFees <= 15, "Aria: Configurable fees cannot be greater than 15");
require(reward >= _minUSDCRewardsFee && reward <= _maxUSDCRewardsFee, "Aria: Reward fee has to be between 5 and 10");
require(treas >= _minLiquidityTreasuryDevMarketingFee && treas <= _maxLiquidityTreasuryDevMarketingFee, "Aria: Treasury fee has to be between 1 and 5");
require(liq >= _minLiquidityTreasuryDevMarketingFee && liq <= _maxLiquidityTreasuryDevMarketingFee, "Aria: Liquidity fee has to be between 1 and 5");
require(devMark >= _minLiquidityTreasuryDevMarketingFee && devMark <= _maxLiquidityTreasuryDevMarketingFee, "Aria: Dev/Marketing fee has to be between 1 and 5");
USDCRewardsFee = reward;
liquidityFee = liq;
treasuryFee = treas;
marketingFee = devMark;
totalConfigFees = USDCRewardsFee.add(liquidityFee).add(marketingFee).add(treasuryFee);
}

For Sell orders there is an additional fee of 3%, MarketMakerPairs is the Defi exchange in our case it will be PanCakeSwap that is how a Sell order is defined. When you are sending it to PanCakeSwap you are selling.

if(automatedMarketMakerPairs[to]){
   fees += amount.mul(3).div(100);
}

We are also introducing a automated reward or fee in the sense of mint or burn based on market conditions and if liquidity pool is over or under liquified. We will rely on Chainlink to get market condition data as well as our liquidity pool condition and based on it decide between 0–3% to either reward 0–3% more by minting in a transaction or to charge a addition fee 0–3% and burning those tokens. Only one scenario can happen and it is mint or burn. In the mint scenario more is rewarded vs in the case of burn the transaction will just transfer less tokens. I am still wrapping up this code and this code is what really makes our project somewhat unique compared to others so I won’t be showing it until it is audited.

Distribute rewards

The distribution of rewards is what we have been testing of late. We have also had many discussions with community members over this as our token is not using rebase it is actually converting our native $ARIA token into USDC and then this USDC is transferred to all token holders. The issue comes up when we starting going up in token holders, lets say 1000, 2000, 5000, or 10000 plus. How much gas will this cost? While we were hoping to implement a reward system of 30 minutes and use covering the cost it would not become sustainable. Instead what we will do is implement a self server dashboard where you will be able to see all your rewards and at any time each individual will be able to claim his or her rewards. While this shifts the gas fees over onto our holders it will save tons of BNB for everyone in the long run on transaction fees as you will be able to withdraw the rewards whenever you feel is right this could be multiple times per day or it could be once per week or once per month.

Multisig

From the very beginning of this project we have been looking into what we can do to earn the trust of the community and to keep everyones rewards safe. We have added many restrains on the contract itself however certain functions need to remain in place in case something does go wrong like the ability to change the treasury wallet or the dev/marketing wallet. So how do you secure those? Well the answer is a Multisig wallet, and how do you make sure the Multisig wallet is secure? Well by including a third party outside of the $ARIA token team. When we did the The House of Obsidian verification we choose the options where they will be part of our multisig wallet. So the $Aria Token Contract will be owned by the multisig wallet and the Treasury will be owned by the multisig wallet and will require everyone to sign of on those transactions. Any of these transactions will be communicated well ahead of time and reasons will be provided for a more transparent approach to our entire project.

KYC (Know Your Customer) and Audit

We have been in communication with Solidity.Finance to conduct our Audit. Once we have completed all testing and verification on our end we will be sending the contract out for them to review it. Once it is submitted for review we will update the community on it and keep you in the loop on recommendations from the audit and timeline for addressing any found issues. Another thing that everyone at this point should be aware of is that we have been verified by the Obsidian Council this is another step that we have taken to insure our community on how serious we are about this project

As always if you have made it this far I want to thank you for supporting $ARIA Token and if you have not joined our community feel free to check us out on Discord https://discord.gg/yfuyJfpARv