-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
For more details about the transfer burn mechanism and its technical aspects, check out the (KIN Discussion Proposal) in GitHub KIN Transfer Burn Mechanism. [Discussion] #25. Your input and support are crucial to the success of this proposal. This way it can make its way into the KIP (KIN Improvement Proposal). Let's make a difference together! 💪
PART-2 I'm bringing the conversation from discord here to just update this as we discuss this and how this is on the record. u/mocolicious — I appreciate your contribution to the discussion. so first, we would have to get people to agree that this is what the community wants to do via the governance voting. After that, the owner of the upgrade authority would have to grant access to the keys. Im not sure if thats possible or who that might be. I think the move is to wait til the governance solution has been tested on some more simple propositions and then we can make a stronger argument about inquiring to who owns it. Else we're talking about starting a new token entirely with the same name, which would also be a difficult proposition. u/CitizenCapet — I'm certainly in favor of seeing if we can update the contract without creating a new KIN. You did raise some valid points. Implementing a transfer burn mechanism in the existing KIN contract without creating a new token will require community consensus and potentially involve some technical and governance challenges. I did some research and this is what could be some possible approaches to address these points: Community Consensus: As you mentioned, it's crucial to ensure that the majority of the KIN community agrees with the proposed changes. Implementing a governance voting mechanism or using an existing one you are developing now, when available, would allow token holders to voice their opinions and vote on the proposal. I wish we could use a pre-existing one that was free and verifiable for KIN holders to use. I found pre-existing blockchain voting protocols that could be utilized for KIN holders to vote on proposals like implementing a transfer burn mechanism. Some of these protocols are free and verifiable, ensuring a transparent and decentralized decision-making process. four voting-free blockchain protocols that KIN can use today if we tinker with them. 1A. Aragon https://aragon.org/ is a platform for creating and managing decentralized organizations. It offers a suite of tools for governance, including voting mechanisms. KIN could potentially create an Aragon organization and use its voting module to let KIN holders vote on proposals. 2B. Snapshot https://snapshot.org/ is a gasless, off-chain voting platform for decentralized governance. Projects can create proposals and let their token holders vote on them using their token balance without incurring gas fees. KIN could create a Snapshot space for the community to vote on proposals. 3C. DAOstack https://daostack.io/ is a framework for building decentralized organizations and managing their governance. It includes a voting module called "Alchemy" which enables token holders to vote on proposals. KIN could potentially utilize DAOstack to create a DAO for managing the project's governance, including voting on proposals. 4D. Colony https://colony.io/ is a platform for building decentralized organizations with built-in governance features. KIN could potentially create a Colony organization and utilize its voting mechanisms to let token holders vote on proposals. Upgradeable smart contracts: If the current KIN smart contract is upgradeable (e.g., implemented using a proxy pattern or similar mechanism), updating the contract to include the transfer burn mechanism would be more straightforward. The upgrade authority would need to authorize the changes, and the new logic would be implemented without affecting the existing token holders' balances or creating a new token. Which I would like to avoid for obvious reasons. Identifying the upgrade authority: To update the smart contract, it's essential to determine who holds the upgrade authority. This could be the project team, a multisig wallet, or a DAO. It might be necessary to wait for the governance solution to be more mature and tested before approaching the upgrade authority with the proposal. But voting on something and implementing it are two things. Non-upgradeable contracts: If the current KIN contract is not upgradeable, implementing the transfer burn mechanism directly within the existing contract may not be possible. In this case, creating a new token with the same name and implementing a token swap mechanism might be a potential solution, though it would indeed be a complex and challenging process. There has to be a way around this. I'm certain this is solvable. @mocolicious — without access to the key with upgrade authority you'd need to create a new token @CitizenCapet — So no one knows who has the key with upgrade authority? How it this even possible being this is an open-source ecosystem? Wouldn't TED have an idea? @mocolicious — it would be a safe presumption that he has it, but you'd have to ask him @CitizenCapet — Well then, I shall ask him. _____________________________________________________________________________________________ In closing, my goal is to get feedback to help the discussion grow in optics and provide any material the community is requesting. I can build almost anything. As long as I have clear instructions as to what is being requested to add. Be cool to have some devs that want to help with the code and debugging once we get the final optics on parameters.