Skip to content

Implement Basic TradedToken #1

@EGreg

Description

@EGreg

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:

  1. totalSupply will set the total supply of the token from the beginning, and default to 1 billion.

  2. transferTax will be a struct with parameter total (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 the progressive tax, which increases gradually from 0 (at from) to total (at to)

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.

  1. progressive would be a struct with parameters from (default 5 percent), to (default 100 percent) and duration (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
}
  1. sell will be a struct with parameters eventsTotal (integer) and afterPriceIncrease (in percent) and slippage (in percent) that discusses the "primary sale" from the faucet when prices exceed historical highs by at least afterPriceIncrease percent.

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).

  1. proceeds determines where the proceeds from the primary sale will go, it will be a struct with parameters toLiquidity and addresses (array of addresses) and proportions (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.

  1. liquidity will be a struct with toBurn which 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 in 4b.

  2. Make the setInvitedBy(invited, inviter) method which takes two address parameters and sets invitedBy[invited] = inviter unless 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions