30. Contribute To Illuvium Game Development By Submitting IIPs Via GitHub
The genesis of the Illuvium project was a desire to make a collectible NFT game that was open, transparent, and governed by the community. The community of $ILV holders will govern and maintain the protocol, via the Illuvinati Council*. It’s worth noting we have modeled the governance process on Synthetix’s governance, and had input from several Synthetix core contributors, who themselves modeled their governance on the Ethereum EIPs and early versions of change control in open-source software.
To read more on Illuvium DAO governance*, review the Whitepaper section here: https://docs.illuvium.io/whitepaper/dao/
*The “eDAO” and “Illuvinati Council” is our initial governance model, and is subject to change. We strive to implement the best models of decentralized governance.
Submit a proposal. It’s your right as an $ILV holder.
Are you a thought leader in the Illuvium community? Do you care about the substantial $ILV investment you made? Do you think about the bigger picture for the whole DAO, and have an idea that would improve the game or tokenomics?
If so, then, submit an IIP!
Illuvium Proposals (changes in the protocol via ICCPs and IIPs) are submitted to the IIP’s Github repository and will be posted on the Illuvium Proposal space. Proposals must reach a supermajority agreement to be enacted.
What is an IIP?
IIP stands for Illuvium Improvement Proposal, it has been adapted from the EIP (Ethereum Improvement Proposal). The purpose of this process is to ensure changes to Illuvium are transparent and well governed. An IIP is a design document providing information to the Illuvium community about a proposed change to the system. The author is responsible for building consensus within the community and documenting dissenting opinions.
What is an ICCP?
ICCP stands for Illuvium Configuration Change Proposal. ICCP’s are documents for making a case of modifying one of the system configuration variables. The intent is to provide a clear and detailed history behind each configuration change and the rationale behind it at the time it was implemented. The author of the document is responsible for building consensus within the community and documenting dissenting opinions.
IIP & ICCP Rationale
We intend IIPs and ICCPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and for documenting the design decisions for changes to Illuvium. Because they are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
It is highly recommended that a single IIP contain a single key proposal or new idea. The more focused the IIP, the more successful it is likely to be.
An IIP or ICCP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement.
IIP Work Flow
Parties involved in the process are the author, the IIP editors, the [Illuvium Core Contributors] and the Illuvium community.
⚠️ Before you begin, you should vet your idea. This will save you time. Ask the Illuvium community first if an idea is original to avoid wasting time on something that will be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will have the intended effect. The appropriate public forum to gauge interest around your IIP or ICCP is the Illuvium Discord.
Your role as the author is to write the IIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful IIP will move along:
[ WIP ] -> [ PROPOSED ] -> [ APPROVED ] -> [ IMPLEMENTED ] X [ REJECTED ]
Each status change is requested by the IIP author and reviewed by the IIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your IIP. The IIP editors will process these requests as per the conditions below.
- Work in progress (WIP) — Once the author has asked the Illuvium community whether an idea has any chance of support, they will write a draft IIP as a pull request. Consider including an implementation if this will aid people in studying the IIP.
- Proposed — If agreeable, IIP editor will assign the IIP a number (generally the issue or PR number related to the IIP) and merge your pull request. The IIP editor will not unreasonably deny an IIP. Proposed IIPs will be discussed in governance discussions on Discord. The council will then vote on the proposal, if the proposal passes it will be moved to the approved stage.
- Approved — This IIP has passed community governance and is now being prioritised for development.
- Implemented — This IIP has been implemented and deployed to mainnet.
- Rejected — This IIP has failed to reach community consensus.
What belongs in a successful IIP?
Each IIP or ICCP should have the following parts:
- Preamble — RFC 822 style headers containing metadata about the IIP, including the IIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details.
- Simple Summary — “If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the IIP.
- Abstract — a short (~200 word) description of the technical issue being addressed.
- Motivation (*optional) — The motivation is critical for IIPs that want to change Illuvium. It should clearly explain why the existing specification is inadequate to address the problem that the IIP solves. IIP submissions without sufficient motivation may be rejected outright.
- Specification — The technical specification should describe the syntax and semantics of any new feature.
- Rationale — The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
- Test Cases — Test cases may be added during the implementation phase but are required before implementation.
- Copyright Waiver — All IIPs must be in the public domain. See the bottom of this IIP for an example copyright waiver.
To read the guidelines, learn formats, see templates, and familiarize with what the Editor responsibilities are, review our IIP page on GitHub:
https://github.com/IlluviumGame/IIPs/blob/master/iips/iip-1.md#iip-editors
See a completed and accepted IIP.
IIP-004 Removal of Locked Tokens from Yield Farming
Simple Summary
The community has highlighted an issue with the current ILV Yield Rewards. The main configuration in question relates to the fact that locked tokens are currently able to stake in the ILV pool or provide liquidity via the ILV / ETH pool and receive Yield Rewards. Allowing locked tokens to be staked in any Yield generating pool reduces the distribution of the ILV token to unlocked token holders, potentially harming the decentralisation of the project. Removing the ability for locked tokens to farm Yield Rewards will substantially increase the APY of both pools, which will incentivize new users to purchase and stake ILV.
Abstract
Automatically place all locked tokens into a newly created ILV pool with a weight configuration of 0 and remove the ability for locked tokens to be staked into the ILV pool or provide liquidity via the ILV/ETH pool that both generate yield rewards. Reconfigure the codebase to recognise this zero weight pool only for the purpose of distribution of Vault Distributions.
Overview
Yield Farming — 3m ILV distributed over 3 years
Pool 1: Unlocked Tokens ILV pool Weight [0.2] — 20% of the total Yield Rewards during periods of no flash pools.
Pool 2: Unlocked Tokens ILV/ETH pool Weight [0.8] — 80% of the total Yield Rewards during periods of no flash pools.
Pool 3: Locked Tokens ILV pool Weight [0.0] — 0% of the total.
Revenue Distributions — 100%
Unchanged. All pools (except flash pools) receive the same weighting for the purpose of Vault Distributions.
Voting Rights
Included in governance:
Pool 1
Pool 3
Excluded from governance
Pool 2
NOTE: A further IIP is currently being developed to suggest a reconfiguration of the codebase to allow Pool 2 to take part in governance. Due to the complexity of this change, it requires a separate IIP that would be deliberated by the council on its own merits.
Rationale
IIP 4 gives the prospective investors more confidence in the overall distribution of ILV, and the APY in the Illuvium protocol. The reduction in total tokens for locked token holders is expected to be far smaller than the increase in value of the token, and as such it makes strong financial sense to implement this IIP for all parties.
Join GitHub to submit IIPs
Illuvium uses GitHub for IIP management because GitHub is a Git repository hosting service. While Git is a command line tool, GitHub provides a Web-based graphical interface. It also provides access control and several collaboration features, such as a wikis and basic task management tools for every project.**
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world. At the time of this post, 65+ million developers, 3+ million organizations, 200+ million repositories are all utilizing GitHub, and 72% of them are Fortune 50 companies or orgs.***
Joining GitHub is easy.
Click this link to register: https://github.com/join
Quick Links:
https://twitter.com/illuviumio
Join us: discord.gg/illuvium
You’ll be hearing more from us soon!
**Finley, Clint. “What Exactly Is GitHub Anyway?” TechCrunch, 14 July. 2012, https://techcrunch.com/2012/07/14/what-exactly-is-github-anyway/
***From the GitHub website.
https://github.com
