YOLO Smart Contracts are Coming to a Blockchain Near You
Our readers may have seen that we released our much-anticipated community Bug Bounty to the public last week. So before we forget, be sure to read our new Medium article, and check out the corresponding Github repo, and head to 👉Immunefi to report bugs and earn some bounty💰.
We realize that the Smart Contract system has a lot of moving parts, and we also realize that getting there may require guidance through the YOLO solar system. In this article, we’ll go through the hierarchy of contract relationships from a top down perspective, describing the contract groups and then the contracts themselves in more detail.
So here we go with a very nice (and very thorough) explainer of our Smart Contract ecosystem…
Architecture
The YOLO system of contracts follows a registry umbrella pattern, where a registry contract contains addresses of all registered singleton contracts, as well as the currently active game (market/pair) markets in operation. All contracts in the umbrella inherit a “registry satellite” base contract, which handles access control and most of the necessary references to other contracts. (You can access this documentation along with more detailed diagrams at https://docs.yolorekt.finance.)
Contracts are broken down into 4 groups:
- Core
This group holds contracts that handle critical management of registration, access control, user essential data, i.e., balances and participation tracking, liquidity pool and its deployment, and satellite contracts configuration. - Game / Market
This group handles factory contracts that are charged with creating specific market types for any arbitrary pair and game duration and contain the implementations of the market contracts themselves.
- XFT / Tokens
This group handles the contracts for our XFT (SFT/NFT) tokens, the mintable/burnable token base contracts for our liquidity contract, and future YOLO fungible token. It also currently contains optional logic to handle user rewards.
- Accessory
This group handles staking rewards for liquidity providers, bidders rewards for platform participants (i.e. market takers), and other ancillary contracts, such as whitelisted sales contracts for XFT issuance.
Deployment
Deployment begins with the creation of the YoloRegistry registry contract, then followed by the singleton contracts, which all depend on the registry contract address and interface. As a one time deployment for any major version rollout, the admin will deploy contracts and configure them to communicate amongst each other, allowing the necessary internal transactions to complete when called by admins and users. Some of the important satellite contracts include YoloWallet, LiquidityPool, GameFactory, YoloXFTPack, and NFTTracker. Game instances for various asset pairs are created from the GameFactory; for users, this GameInstance contract is the most relevant contract.
Singleton Contracts Instantiation
The YoloRegistry contract is the “master” contract establishing the primary admin address and subsequently registers all of its satellite contracts, including the game/market contracts. When deploying each satellite contract, the contract under creation will typically need to make a call to the registry contract in order to pull address dependencies from the contract registry storage via a contract identifier key. Consequently, each deployed contract must be immediately registered within the YoloRegistry for the deployment sequence to advance to completion. For example, when the LiquidityPool contract is instantiated, its constructor will pull in the YoloWallet address as a requirement from the YoloRegistry contract, since it is a critical dependency where on-platform balances are tracked.
Game/Markets Instantiation
The GameFactory contracts are in charge of minting new game instances for a given asset pair and round length (time duration). Already existing doubles of a given asset pair identifier and length will revert, unless a new starting round offset is provided to the game creation invocation. The current design requires the game/market to be registered in the registry contract before it can be minted. This is possible through the use of the create2 opcode in order to approve a contract address before the contract itself exists (counterfactually).
Operation
Administration
Administrative privileges via access control checks on certain smart contracts are necessary for operation of the YOLOrekt system of Smart Contracts:
- GameInstance
Admins maintain the functioning of the markets by processing rounds at settlement time in each game contract in regular intervals. Fee rates are adjusted dynamically per market according to liquidity conditions as well as market velocity and volatility. Using a proprietary market making algorithm, liquidity is deployed into market rounds from the liquidity pool into game contract balances.
- XFT contract
The XFT contract consists of a SFT/NFT pack with various token levels (or series). Each level has a maximum token capacity which is set and adjusted by admins to limit the token balance of each level (i.e. token basetype). Rules as to how the level 1 token (lowest level) can be minted by users are determined by the admins who encode the rules into ancillary contracts, which are given minter role privileges on the XFT contract.
- XFTTracker
This contract coordinates user participation statistics across game/market contracts and rewards contracts. Importantly, the admins set level threshold requirements that are cross-referenced by the XFT contract when determining whether a user is qualified to make an upgrade request to level up their token. For each token level, the admin also sets a rewards multiplier value that is applied as a XFT level-specific weighting, when the organization provides and distributes incentives.
Additionally, sanity checks are set in place across contracts, by a combination of hard-coded and dynamic variables to guard against nonsensical, damaging configurations, without which errors may result, leading to funds losses or denial of service. For example, unintended mistakes such as fat finger transfer of liquidity into markets, too large or small fee rate values, or setting round settlement timestamps far into the future with the unintended effect of locking up bidders funds are minimized or eliminated altogether.
Users
Users have specific actions that can be taken on a limited number of contracts exposed to them directly, facilitating focus on the game play and social finance aspects of the platform.
Contracts with exposure are:
- YoloWallet
Withdraw funds, set unique ASCII encoded username, deposit funds (not needed, see GameInstance)
- GameInstance
Bid in rounds by round index, claim returns from settled rounds (250 rounds at one time). Depositing funds directly onto platform is unnecessary as long as a game contract has approval from user in the settlement asset token contract (USDC stablecoin); any shortfall amount not encumbered in YoloWallet will be auto-transferred to the wallet and notated to the market account.
- XFT Contract
Users are able to transfer their tokens to any other address. Each address can only hold one XFT token at a time. This restriction applies across the combined set of all levels.
Liquidity Providers
Liquidity providers interact directly with the LiquidityPool contract, which itself derives from a mintable/burnable ERC20 contract. The liquidity provision feature is straightforward, requiring only a minimum deposit balance to be maintained when making liquidity deposit requests into the pool. Depositing liquidity will return an ERC20 LP share token to the liquidity depositor. Withdrawals can be made at any time from the pool.
Liquidity is managed passively through a proprietary algorithm. The algorithm funds rounds in active market contracts using a very small portion of the funds (<1%). Fees and earnings from the rounds are returned with every settlement, approximately every 3 minutes as a lower bound. Fees returned are a minimum of 3% of the round pool account. A small fraction of fees are encumbered in a treasury account. The YLP tokens are interoperable with other platforms, which support ERC20 tokens, and are also to be used with the YOLO staking rewards contract, once it is available.
Audit process
We’d also like to mention diligence. Security audits have commenced over the course of 3 months with several auditors managed through QuillHash. In addition, a well respected SushiSwap core developer (among other things) was consulted at regular intervals, as the team drilled down on the continual reduction of attack surfaces in the system of contracts. The results of the audit will be posted by QuillHash soon.
Reporting bugs
Post a PR or issue in our YOLOrekt github repo with the following sections: impact, the vulnerability, and steps to correct. Report bugs at 🐞Immunefi🐞. Head to our Discord channel #bug-reporting and give us a heads up or shout for help on reporting! You can also find the linked task on Dework at our YOLOrekt Main Space.
About YOLOrekt
YOLOrekt is building a comprehensive short-term prediction platform for crypto, stocks, and more. YOLO is a social and fun way to bid on the future price of an asset. Provide in-game liquidity to earn game fees and YOLO rewards.
Visit us at yolorekt.finance
