-
Notifications
You must be signed in to change notification settings - Fork 2
Description
We need a TradedTokenContract whose instances are produced by TradedTokenFactory method produce that takes required parameters, and perhaps a struct of optional parameters.
The token should write informative events to logs after every action, such as after adding liquidity ini 2a or 4a, announcing that it has thrown away 90% of LP tokens, etc.
The token would be an ERC777 token, but totally ERC20 compatible. All tokens will be pre-minted.
Its transfer function would support the following behaviors, depending on the parameters named below. Please note that all parameters should be able to be specified during produce() method of factory, otherwise use defaults. Please rename existing parameters to the structs and property names listed below. If structs don't work then concatenate the names with camel case, such as sellEventsTotal and sellAfterPriceIncrease:
-
totalSupplywill set the total supply of the token from the beginning, and default to 1 billion. -
transferTaxwill be a struct with parametertotal(by default = 0) of the total token amount transferred will be deducted from every transfer where the sender or recipient is not the smart contract itself, and where sender is not the liquidity pool of the token vs WETH. Actually see 2d for theprogressivetax, which increases gradually from 0 (atfrom) tototal(atto)
2a. The toLiquidity would be the fraction of the tax to swapAndLiquify as with SAFEMOON from the tax.
2b. toBurn would be the fraction of the tax to simply burn the tokens, both 2a and 2b can be expressed in percent
2c. The remaining amount total – toLiquidity – toBurn will be sent to the account which invited the sender (see section 7 below) if any, otherwise it is also burned.
progressivewould be a struct with parametersfrom(default 5 percent),to(default 100 percent) andduration(default 3600 seconds). You can set a flat tax by making from=to=0. The tax from any transaction is calculated by the following algorithm:
transfer(address recipient, unit256 amount) {
if (transferTax.total == 0 || msg.sender == address(this) || recipient == uniswapV2Pair) {
return; // don't take any tax
}
if (block.timestamp > (recentTransfer[msg.sender] || 0 ) + progressive.duration) {
recentTransfer.timestamp[msg.sender] = block.timestamp;
recentTransfer.balance[msg.sender] = balanceOf(msg.sender);
recentTransfer.sentPercent = 0;
}
sp = recentTransfer.sentPercent;
pt = progressive.to;
pf = progressive.from;
p = recentTransfer.sentPercent + amount.mul(100).div(recentTransfer.balance[msg.sender]);
taxP = p < pf ? 0 : (p+sp).div(2).sub(pf).div(pt-pf).mul(transferTax.total);
recentTransfer.sentPercent = p;
// now apply the tax and distribute it
}
sellwill be a struct with parameterseventsTotal(integer) andafterPriceIncrease(in percent) andslippage(in percent) that discusses the "primary sale" from the faucet when prices exceed historical highs by at leastafterPriceIncreasepercent.
On every transfer, check whether the recipient is the liquidity pool of [WETH, the token]. If so, do latestPrice = price1CumulativeLast() using the Uniswap API to get the latest price of the token relative to WETH. Then calculate priceExcess = latestPrice - latestMaxPrice * (1 + sell.afterPriceIncrease). And if priceExcess > 0 then you are supposed to sell sell.tokenAmount = totalSupply().div(sell.eventsTotal).mul(priceExcess / sell.afterPriceIncrease).
proceedsdetermines where the proceeds from the primary sale will go, it will be a struct with parameterstoLiquidityandaddresses(array of addresses) andproportions(array of percentages which must add up to 100)
5a. The toLiquidity (default 10) will be the percent of the proceeds from a primary sale that will be going to liquidity, but not using swapAndLiquify. Instead, the contract will calculate amountToken0 = token0Received.mul(100).div(toLiquidity) from the amount of token0 (WETH) that was received as a result of the sale, and also do amountToken1 = latestPrice * amountToken0, and addLiquidity() of amountToken0 and amountToken1 allowing any slippage. Note that the amountToken1 tokens are taken from remaining amount of totalSupply minus totalInCirculation.
5b. The remaining percent of WETH received after toLiquidity will be disbursed to accounts in addresses according to proportions.
-
liquiditywill be a struct withtoBurnwhich is the percent of LP tokens to burn after adding liquidity in 2a and 4a. The remainder will be disbursed in the same exact manner and proportions as in4b. -
Make the
setInvitedBy(invited, inviter)method which takes twoaddressparameters and setsinvitedBy[invited] = inviterunless it was already set. And this is what is used in 2c.
7a. You should have a mapping called balances[address] and if any account uses transfer to send to an account that was not in the mapping or had zero balance, then you also should set invitedBy[recipient] = msg.sender and that account becomes the "inviter" automatically.
Add all the above information to README, to describe parameters in user-friendly tables, and then implement it.