ACPI project (self-construction of the initial price)
The ACPI project aims to identify the initial selling price of a token through various exercises of selling a very small portion of the available tokens. As we have seen in the multiple projects that have launched a token, using various methods of selling and making available tokens (lock, non lock, pools, airdrop and other), a common point was the starting price, 2 ways are repeated for almost all projects, the first set an arbitrary price by a handful of people who estimate according to various criteria the value of the token, the second is to list with low liquidity and an extremely low price.
In the first case it is unlikely that people involved in the project can actually find the value of the token, this usually leads to a collapse of the price from the beginning For the second case, because the price and low liquidity is very low, the price has a tendency to explode upwards violently to quickly collapse making the happiness of the boot who manages to buy very low and resell during the rise, this creates immediate losses for all those who enter, loss that can remain several months or year before regaining the highs of the launch
RealT Inc. is drawing conclusions from the experiments of other players, and as we do not want to offer this experience for the governance token that will be put on sale soon, we are going to experiment with a new approach, the ACPI. RealT not being a seer we cannot give a price to the token, the market being irrational and parasitized by scavenger boots bringing nothing to the project (we do not speak about the arbitrator boots which is vital), we have worked on this solution which allows the market to determine the initial price with the sale of a small exchange of tokens with various mechanics giving all prices which will be consolidated to obtain an initial market price.
The objectives of the ACPIs are therefore to experiment with different prices through 4 sales methods, each of which will be reproduced several times to obtain a sample price which will then be consolidated between the 4 ACPIs to give the initial price. Another important objective is to concretely involve the community from the beginning in the life and emotion of this token, being a DAO governance token, we are convinced that the initial price should not be established by a centralized entity, but by the people using it who have an interest.
ACPI 1 - Similar to an auction, in each session a token is put up for bidding, interested parties will bid to win the token. At the end of several bidding sessions, the contract will take the median value of all the bids to set the ACPI 1 exit price
ACPI 2 - Participation method where the amount is determined by the user, with each session a token is put on sale, Every participant deposits an amount of their choice into the common pot, at the end of the session the total sum of the pot determines the value of the token and each participant receives a proportional share of the token compared to its deposit in the pot. At the end of several sessions the contract will take the average value of all the ACPI 2 sessions to set the ACPI 2 exit price.
ACPI 3 - Similar to ACPI 2, it differs by having a single participation with a fixed amount in the pot, at the end of each session the total sum of the pot determines the value of the token and each participant receives an identical share of the token.
ACPI 4 - Selling with a tiered price aims to determine the ceiling price, it resembles a low price bid in a liquidity pool with little available liquidity, however in ACPI4 this is done in a controlled environment, each session starts with a low price and increases each round by 60%, each round has an identical number of tokens offered for sale at the prices set by the contract, an investor can only buy one token at a time, but can participate in multiple sessions and each round of the same session. The round of a session ends when all the tokens of the round are sold or if at the end of the timer the tokens are not completely sold. The final price of a session is determined by the contract by taking an average between the sale of the last round and the penultimate round. At the end of several sessions the contract will take the median value of all the ACPI 4 sessions to set the exit price of the ACPI 4
The final consolidation allows the initial price to be determined by taking the outputs of all 4 ACPIs and applying a degree of impact in the value of the token for that initial sale, this further limits attempts at manipulation and would make it very expensive to manipulate the price.
Once all the ACPI's have been completed, the tokens are released and available for claim by the users, it is possible to delay this step to make the claim available at a later date.
Realt.co
Live website
·
Report Bug
·
Request Feature
Table of Contents
- npm
npm install npm@latest -g
-
Clone the repo
git clone https://github.com/real-token/Realtoken-protocol-v1-contract-step0.git
-
Install NPM packages
npm install
-
Setup a
.envfile, with the following configCoinMarketCap API Key here
Infura API Key here
Etherscan API Key here
ETHERSCAN_API_KEY=API-KEY POLYGONSCAN_API_KEY=API-KEY BSCSCAN_API_KEY=API-KEY REPORT_GAS=CoinMarketCap-API-Key XDAI_URL=https://rpc.xdaichain.com/realt BSC_URL=https://bsc-dataseed.binance.org/ POLYGON_URL=https://polygon-rpc.com/ RINKEBY_URL=https://rinkeby.infura.io/v3/API-KEY GOERLI_URL=https://goerli.infura.io/v3/API-KEY KOVAN_URL=https://kovan.infura.io/v3/API-KEY POA_URL=https://sokol.poa.network POLYGONTEST_URL=https://rpc-mumbai.maticvigil.com/ BSCTEST_URL=https://data-seed-prebsc-1-s1.binance.org:8545/ TOKEN_ADMIN_PUBLIC=Token_Admin_Public_Key ACPI_MODERATOR_PUBLIC=ACPI_Moderator_Public_Key DEPLOYMENT_WALLET=DeploymentWalletPrivateKey DEPLOYER_ADDRESS=Create2Deployer Contract Address
The Real Estate Governance Smart Contract suite is now ready for testing, compiling, auditing, and deploying.
- Run tests
npx hardhat test- Check coverage
npx hardhat coverage- Verify already deployed smart contract on Etherscan.io
npx hardhat verify CONTRACT_ADDRESS --network NETWORK_ID- Deploy and verify on etherscan.io REG and ACPIMaster contract
npx hardhat run scripts/ethers/deployEtherscan.ts --network NETWORK_ID- Deploy Create2Contract
npx hardhat run scripts/web3/deployCreate2.ts --network NETWORK_ID- Deploy with Salt (Predict deployment address) REQUIRE DEPLOYER_ADDRESS env var
WEB3 : npx hardhat run scripts/web3/deployWithSalt.ts --network NETWORK_ID
ETHERS : npx hardhat run scripts/ethers/deployWithSalt.ts --network NETWORK_ID
- Deploy REG and ACPI master at random 0x
ETHERS :
npx hardhat run scripts/ethers/deploy.ts --network NETWORK_ID
WEB3 :
npx hardhat run scripts/web3/deploy.ts --network NETWORK_ID
- Get primary signer nonce for current network
npx hardhat run scripts/getNonce.ts --network NETWORK_ID- Increase by 1 the nonce of the primary signer for the current network
npx hardhat run scripts/increaseNonce.ts --network NETWORK_ID- Increase primary signer nonce for the current network until it reaches target nonce.
npx hardhat nonce --target 15 --network NETWORK_IDNETWORK_ID is specified inside config
In order to ensure the reliability of our contract, we designed an end-to-end test that features 100 users across each of the 4 ACPIs. It verifies that the price for all ACPIs matches and the rewards are all in line.
The report is available here
Use the following command to start the test
npx hardhat test test/end2end/index.test.ts
The following syntax will appear in the report:
102: 5.332486580477705241 - 0.262922728291408962 - 13.15
-
102 is the index of the user you can referer to the report result tab
-
The first value 5.3324... :
tokenToClaimvalue, what the user will be able to withdraw at the end of the ACPI event, you can check that value in the report -
The second value 0.2629... is the amount of tokens rewarded by the bids that were not the top bidder during ACPI #1 you can check that value in the report as
PendingReturns -
The third value 13.15 : The total of bids that were not the top bidder during ACPI #1 ACPI #1
Following the ACPI event, user #102 will be able to collect the sum of his winnings, for example: ~5.33249 REG
Auditing the solidity code in an important aspect of this language, we need to be confident with the code we ship to the customer to avoid malicious attacks
A lot of the auditing have been done during the contract construction using the Solidity static analysis framework Slither
You can download Slither and use the following command to audit the code
slither .- Main contract ✅
- ACPI 1 ✅
- ACPI 2 ✅
- ACPI 3 ✅
- ACPI 4 ✅
- Testing ✅
See the open issues for a full list of proposed features (and known issues).
If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
Distributed under the MIT License. See LICENSE.txt for more information.
Support - @RealTPlatform - support@realt.co
Project Link: https://github.com/real-token/Realtoken-protocol-v1-contract-step0