Heyy, it’s Yaron
Moonbeam Governance Guild & Treasury Council member from Berlin, Germany.
With Moonbeam & Moonriver I’ve been engaged since prelaunch and deeply submerged in all of Gavin’s brainchild’s ecosystems along the way.
For many parachains and system parachains in the ecosystem I’ve been running ExtraCoin nodes for some years.
`I enjoy going to blockchain conferences around the globe and tech innovation in general. My voting perspective on proposals might bias towards game-theory, tech- and economical-feasibility over marketing oriented reasoning and the likes, but I’ll try to free myself from personal biases as much as possible through engaging in constructive discussions with other members of the guild and outside of it.
For an extended introduction I’ll refer to my current terms TC candidacy post instead of copy-’ing.
Any additional GLMR delegations will serve me to first and foremost vote in the token holders best interest & for a flourishing ecosystem
Reasoning: Misconfigured XCM transfers resulting in failed minting executions on MB and user funds being locked-up on MB’s Sovereign account on Polkadot Assethub due to a technical upgrade – clearly refunding the accounts affected by this technical misconfig is the right thing to do here.
Reasoning: S**t happens. Apparently we are looking at a case of simple yet consequential user mistake with lessons learned the hard way, presumably. Once again a great example of the power of Substrate and expedient, good Governance on Moonbeam. Funds that would have been forever lost in most other networks can be recovered through good governance.
Miscellaneous: For testing purposes, on proposal #79 I voted via Nova Wallet’s integrated MB Gov Vote tab and on proposal #80 via the Moonbeam Governance Dashboard as done in the past. Interestingly Nova natively calls the substrate extrinsic while the MB Gov Dashboard goes through EVM system contract calls which is most noticeable through comparison in fees incurred. 0.169126 GLMR vs 0.00151 GLMR. That’s a smooth 100x!
Consequently, both regular Governance votes are displayed in different activity tabs in Subscan.
While Nova’s UX flow & conviction selection is very smooth, the MB Gov Dashboard provides a lot more and more digestible information on the proposal in question.
Reasoning: Simon and I, we are both members of the Governance Guild and among the candidates running for re-election as non-Foundation members in the Treasury Council. For that matter I ABSTAIN from all seven referenda related to the Treasury Council elections to ensure unbiased neutrality of the funds delegated.
Reasoning: The two component’s risk assessment & auditing appear to have been done thoroughly. For that matter, xcvBNC and other LST’s / LSD’s will bring nothing but value to an established DeFi ecosystem on Moonbeam and further fuel cross-chain activities on top of that. Obviously, the Bifrost team has battle-tested substrate LST expertise. AYE!
One might ask why the Treasury would need more assets at all?
So far the Treasury Council has managed to operate at a surplus on a term-over-term basis and to my knowledge no proposals were rejected due to a great lack of funds.
As a member of the Treasury Council I might be biased, however I see two likely scenarious of such changes coming into effect, both of which I consider to clearly be very positive on the development and self-sustainability of the ecosystem overall.
1.) Ecosystem Growth & Development Firepower
Increased treasury assets would enable funding for more ecosystem projects (such as stakeglmr.com and others), generating overall value and stimulating activity across all sectors. This could cause a self-reinforcing updwards spiral, attracting even more development and igniting overall ecosystem activity even further. Such network effects should not be underestimated - we’ve already observed increased project interest following the announcement of Ref 90.
2.1) Self-Sustainability
The additional assets represent a significant step toward shifting recurring costs away from the MB Foundation, improving the networks’ independent economic self-sufficiency. The Treasury Council, predominantly composed of non-Foundation members, helps decentralize executive decision-making and empowers the community directly.
2.2) Transparency
Moving operational costs from the MB Foundation to the Treasury Council would significantly increase transparency and on-chain visibility for Moonbase Alpha, Moonriver, and Moonbeam operations. This transition enables greater community participation, constructive criticism and support.
In conclusion, I strongly endorse Gauntlet’s proposal (giving credit where credit is due, I witnessed @dev0_sik suggesting redirecting PBR staking rewards to the on-chain treasury long before that). The detailed reasoning presented in Gauntlet’s post has received unanimous positive feedback following constructive discussions.
AYE!
Reasoning: “Inflation Reduction Act 2.0” – Runtime upgrade 3400 introduces two significant changes: Increasing the transaction fee burn rate to 100%, strengthening GLMR’s long-term deflationary trajectory, and reducing EVM minimum gas transaction costs by a whopping 75%, which will substantially improve user experience during normal network conditions.
RT3400, already successfully tested on both Moonbase and Moonriver, brings numerous improvements and changes. Implementation is scheduled for January 27th, 2025.
AYE!
Reasoning: This will free up Dwellir’s 1,000 GLMR submission deposit, which of course I fully support. The usual technical process for submitting their valid RPC services payout claim was not available at the time of their submission which the Treasury Council only became aware of due to their unexpected and erroneous root track proposal. We forwarded the issue to the respective engineering department at MBF where swift action was taken and an interim solution put in place instantly. As someone who witnessed the situation develop firsthand, this voting decision is a crystal-clear AYE!
Note 1: Ref. 92 I intentionally abstained from voting due to it’s erroneous content.
Note 2: I’m adding a Track parameter to my list of voting activity parameters. Since delegated funds automatically follow the delegate’s voting direction with their own respective conviction (which they were delegated with in the first place), there’s no reason to mention Conviction separately for this explicit MGG account for now. This may change at some point in the future.
Reasoning: I abstained from voting as Ref 94 was erroneously submitted in the Root track and therefore “[DO NOT VOTE]” was added to its title very soon after. As no submission deposit was placed the referendum simply timed out with no deposit getting slashed.
A Root track referendum requires a deposit of 2m GLMR.
Reasoning: An XCM misconfiguration on Polkadot’s Assethub system parachain with bidirectional HRMP channels to Moonbeam open resulted in one unlucky user’s transferred funds to not mint their respective xc-tokens on Moonbeam as expected after locking the user’s tokens on Assethub in the first phase of the transfer. Moonbeam’s sovereign account on Assethub still holds the users tokens that were locked during the interrupted XCM transfer — Releasing these tokens and refunding the user, who got into this situation through no fault of their own, seems very reasonable to me. AYE!
Reasoning: WASM Runtime Upgrade 3401 which includes a hotfix for RT3400, fixing the Treasury spending flow issue by introducing a new Treasury Proposal flow described by Alberto here. An RT upgrade proposed by the Moonbeam Council with the referendum submitted by trustworthy MBF member Piotr — AYE!
Reasoning: Registering Laos Parachain’s native token “LAOS” as foreign asset xcLAOS on Moonbeam will allow another Polkadot parachain’s native asset to enter Moonbeam and bring value to the ecosystem while allowing the Laos parachain to tap into Moonbeam’s broad DeFi ecosystem and easily benefit from the extensive EVM capabilities and distribution. Required DOT deposits for bidirectional HRMP channels are most likely to far outweigh the added value for both networks — AYE!
Reasoning: This is the same proposal which was previously submitted erroneously in the Root track as Referendum 94. Another parachain to register an asset which is natively deployed on their end, on Moonbeam via createForeignAsset for the mutual benefit of both chains — love to see that. Again. Aye!
Reasoning: This proposal is related to one aspect of the two recent new foreign asset registration proposals on Moonbeam that requiere the origin track General Admin. On both proposals I had previously voted AYE. Submitted by Piotr from MBF. Aye!
Reasoning: Polkadex hasn’t renewed its parachain slot in Polkadot so closing HRMP channels with Moonbeam is a no-brainer. utility.batchAll call inspected. Aye!