TokenSale Platform — Scope of Work
Support our original Pomelo proposal HERE!
TokenSale System Architecture and Use Case Description
We present here our idea for a decentralized Token Sale platform, which will allow for project owners to set up a token sale, determine the token sale parameters, and deploy their sale onto the EOS Mainnet.
The idea for this project is to build an open-source contract that any project can use to sell its tokens. We will then implement these smart contracts to build the EOSTARTER Token Sale platform. We understand that there may be projects that just take the smart contract and run their own token sale based on this contract. However, we are building a great community and a vast network of skilled individuals ranging from developers, marketers, and community builders. Our thesis is that projects will prefer to leverage our know-how, network, and community, and part with some tokens and the token sale fee, rather than launching the sale by themselves.
TokenSale System Architecture (for the End-User)
TokenSale platform — Investor UseCase
Let’s first describe what we would expect a great token platform to behave like and how it will work from the user’s perspective and then the architecture diagram will be easier to understand.
Let’s Define the basic Use Cases (processes) the user will go through:
Login/SignUp:
In our case, we want to be able to inform the user when a token sale that he/she subscribed to is launching, and what his/her allocation is based on the requirements (eg. Staked tokens + NFTs). However, the platform could also be built to work ONLY with the connection of the user’s EOS Account.
Not much to add here. User Logs In, connects EOS Account and is ready to go.
Account Verification:
The Account verification does not fall under the scope of the Smart Contracts for this specific project, but it is important for us as we want to be fully compliant and avoid any potential issues.
Ideally, we would love to be able to leverage EDEN on EOS as our account verification and be completely autonomous within our community to verify who is participating in the sales. However, we don’t live in an ideal world and we still need to comply with regulators, and for that purpose, we will be using a 3rd party KYC provider to provide account verification services.
Pool Subscription:
Once a user is verified, he/she can subscribe to an active project pool. There will be a number of active pools (1 or more) to choose from. The subscription has to be done before the established deadline or it will be unavailable.
Once the user selects a project pool to subscribe to, a subscription request is made. This triggers a requirement check from the BackEnd to verify that the user meets the criteria established by the pool for participation. These requirements may be holding a certain amount of tokens, NFTs, being part of a whitelist, etc. Once the requirement verification is done, a Disclaimer and Agreement is displayed to the user which explains the terms of the investments and also any potential legal disclaimers or acknowledgment that states that the investment is the user’s responsibility. This agreement will be signed ON-CHAIN to provide ever-lasting proof that the account indeed agreed to the investment terms.
Once this transaction is signed, the user will be added to the whitelist of the smart contract, allowing the account to participate in the token sale once it is live. The user will then get an email confirmation that he/she has been added to the whitelist.
Pool participation / Contribution:
When the Token Sale is live, the user logs in and connects with his/her EOS account. The “Live Pool” will immediately be presented and the option to contribute will appear.
User selects “Contribute” which triggers a “Contribution Request”. The smart contract then performs the following checks:
- “Is the user whitelisted/allowed to contribute?”
- “What is the maximum amount allowed for this user”?
The response from the smart contract will enable the system to show the user the amount he is allowed to contribute. The user can select LESS than the established allocation, but NOT MORE. Once the user selects the amount, a transaction is created for him/her to sign and once this transaction is signed, the respective EOS gets sent to the Project Pool Account.
Token Claim / Vesting:
User logs in and navigates to his/her pools. A list of participated pools will appear and the user selects the pool that he/she recently contributed to. A request for the available/total allocated tokens will be sent to the Smart Contract and with that response, the claimable tokens will be displayed to the user.
User can then choose how many tokens of the currently vested tokens he/she wants to claim, and sign the “CLAIM” transaction. Once signed, the smart contract will then transfer the claimed tokens to the user, and those tokens will then be deposited on the user’s EOS account.
— End of Flow —
Architecture Diagram
Token Sale (for Investor) — System Flow Diagram
TokenSale System Architecture (for Project Owner)
Login/SignUp & Account Verification: same for all users (see diagram above)
Pool Submission:
The user will submit a request to submit a project. At this stage, ONLY approved accounts will be able to submit a project pool. This will allow us to verify the projects and filter out potential scams or fake pools.
If the request is approved, a form with the project details will be displayed to the user and should be filled in accordingly. Once details are submitted, the user can save or submit the project details. Once a user submits the project details, a new project pool will be created in the system, but there will not be a smart contract deployed yet.
Users can then submit a “Create Pool” Request. The specific terms and conditions are then fetched and sent the agreement to the user. The user then signs an “Approve and Create” transaction, which sends the confirmed transaction to the backend, which in turn creates the Token Pool Smart contract and deploys it to the EOS Mainnet. It is important to notice that in this design, project pools are owned by the BackEnd Account. This can later be modified to provide ownership of the smart contract to the project owner.
Token Deposit:
At the time of creation, the token pool is not receiving transactions and it is rejecting all transactions both for security concerns and to enable the contract to have exclusively the tokens that will be allocated during the token sale.
The project owner then sends a request to open the pool for deposits to the Pool Contract. Only the project owner can perform this action. once approved, the project owner can then transfer the desired tokens to the smart contract. Once the transaction is confirmed, the BackEnd registers the existing supply and marks the project pool as “Ready for Sale”.
Proceeds Claim:
Users contributing to the Token Sale deposited their EOS to the token sale smart contract, therefore it is not yet available for the project. The project Owner must claim the proceeds from the token sale from the smart contract.
The project owner then submits a request to claim the proceeds. Security checks are done and the vested amount is determined according to the token sale conditions. Once the vested proceeds are determined, the amount to claim is displayed to the user.
Users can now sign a “Claim” Transaction to the Token Sale smart contract, which will then transfer the EOS to the account established as the Token Sale beneficiary during the project pool definition.
Token Sale (For Project Owner) — System Flow Diagram
Conclusion
This is a preliminary system architecture for the Token Sale platform, but it lays the foundation for the major use cases, their flow, and the required development to implement them.
We are working with some of the best EOS developers to bring this platform to life as soon as possible and with your help, we will speed up the development and deploy the EOSTARTER Token Sale platform very soon. The Token Sale smart contract that we will use in our platform will be published as open-source for anyone to use and submit improvement proposals.
We want to thank you for reading this far and for considering contributing to our pomelo grant request at:
