Issue #3

[BytePhoenixCoding]

OLD: some stuff still applies like layout etc but I've now done the backend code

Prob the most difficult issue of them all, but is v important.

Here we've got the Create Token mockup. I programmed it myself (just playing about with UI elements to kinda get it to what I like), in the photo it's different to what I originally had as I had to change how it works. Apologies as its kinda shitty just done in paint, but you'll get the idea I think lol.

Very simply, it's a simple UI where users can create their own tokens and automatically add liquidity. I want it to be as easy as possible for the user to create a token, so a 5yo could do it lol.

Step 1
There will be a dropdown box where the user selects a token template. There will be multiple templates which I can add (eg. Basic, Deflationary, Fees, LiquidityGenerator etc).

Each token template will always have 2 core parameters (name, symbol)
Some token templates will have additional parameters, eg. Total supply, BuyFee, Sell fee etc. Total supply is included in the additional parameters even though it should be a core parameter (sorry to be confusing lol, just the way I coded the contract)

Since there will be new templates added (regularly?) I propose that I make a json file, and the UI interprets that (so when the user clicks on eg. Template #3 for example, it shows the relevant fields that only apply for template 3). This will prob be the hardest thing I'm guessing, I can work on some JS to better interpret it into arrays etc if u want, just lmk.

Example json file so u know what I mean:

{
   "Template 1":[
      "Total Supply"
   ],
   "Template 2":[
      "Total Supply",
      "Extra Parameter 1",
      "Parameter 2",
      "Parameter 3"
   ],
   "Template 3":[
      "Total Supply",
      "Extra Parameter 1"
   ]
}

All parameters are uints (whole numbers): the contract only has the capability to deal with a uint array as token params.

Token shares

Obviously it would be a bad idea to give the token owner most of the tokens as they could just dump them and run off with the liquidity lol.

What I've done is implement a max owner token share. Currently the token creator cannot hold more than 25% of the token which I think is pretty fair, may change it later idk.

The user should be able to edit the owner token share (and be prevented from entering a too high number). U can get the max token owner share by getting the value from the FilterManager contract (read function).

There should be a label 'Amount held in LP', which should just be 100 - owner token share from above.

Step 2

Obviously to make a liquidity pair there has to be 2 tokens. The pair's first token will obviously be the created token, and the 2nd will be the base token.

I think in the majority of cases the base pair will be BNB, so that can be displayed by default. The user can change it to any other verified token (UI must check if base token is verified, u will know how to do it by now from previous task lol).

Liquidity lock

There should be a function to lock liquidity. The user can either lock liquidity forever or select x number of days. It should be the same as in the add liquidity UI.

Token mint fee

Another way for us to grab money is to charge a 'token mint fee'. It's set as a percentage of liquidity, currently I'll set it as 0.3%
(so if user adds eg. 1000 BNB, 3 BNB will go straight to filterswap, same as for BUSD or any other pair etc).

Approve

If the base token is NOT BNB (let's say BUSD), then the user will need to approve their BUSD to be spent by the Deployer contract (get address from info post earlier on), submit Approve function to BUSD contract with spender as Deployer contract, and amount as type(uint).max (eg. 2^256 -1). User clicks on Approve button, metamask prompt pops up, user submits then green confirmation or whatever (same fashion as on swap page when u click approve).

If base token is BNB, grey out the Approve button as it's not relevant.

Create Token

Here comes the fun part. Actually creating the token. Quite a few parameters that need to be submitted but it's not that complex really.

I won't write it here, but look at the parameters on BscScan, should make sense to u: https://testnet.bscscan.com/address/0x5E8ef51dd4aFCfB08636CB250801D994af05bD04#writeContract

Scenario #1: Base token is BNB

The createTokenWithETH function will be used.

msg.value =Input amount (eg. 1 BNB)
_tokenType = a number corresponding to which template (eg. 1st template = 0, template 3 = 2, just calculate it from position of json file).
_tokenName = user supplied token name
_tokenSymbol = user supplied token symbol
_tokenArgs = uint array of token parameters. First should be total supply, then eg. buy fee, sell fee if needed eg. [10000, 5, 5]
_ownerShare = owner share percentage (in whole number eg. 0 - 25)
_deadline = addLiquidity function deadline, just set to (2 ^ 256 -1) probably for now
_liquidityLockTime = liquidity lock time (either x days * 86400, or (2 ^ 256 -1) )

Scenario #2: Base token is eg. BUSD

The createTokenWithAltPair function will be used.

msg.value = 0 (not providing BNB to contract)
_tokenType = a number corresponding to which template (eg. 1st template = 0, template 3 = 2, just calculate it from position of json file).
_tokenName = user supplied token name
_tokenSymbol = user supplied token symbol
_tokenArgs = uint array of token parameters. First should be total supply, then eg. buy fee, sell fee if needed eg. [10000, 5, 5]
_baseTokenAddress = address of base token eg. BUSD
_baseTokenAmount = amount of tokens
_ownerShare = owner share percentage (in whole number eg. 0 - 25)
_deadline = addLiquidity function deadline, just set to (2 ^ 256 -1) probably for now
_liquidityLockTime = liquidity lock time (either x days * 86400, or (2 ^ 256 -1) )

All elements should be in the style of PancakeSwap UI as much as possible (ie. imagine how PancakeSwap would have implemented it lol)