Hey all, my name is Rafael Castaneda, aka “CastaCrypto”.
I’m a content producer, community founder and builder in the BR crypto space, and a great enthusiast on web3 governance innovation.
My background is on software, being a MSc in Computer Science by the Military Institute of Engineering in Rio de Janeiro with +20 years as a developer and professor/researcher on academia.
Since 21 I migrated to crypto, and now I create educational content in PT-BR being regarded as one of the top authorities in crypto on Brazil.
On Moonbeam I’m the founder and leader of MoonVilla (https://moon.villas) an engage-2-earn community that employs a novel tokenomics approach on socio-economical incentives for community building called “Valocracy” (https://valocracy.xyz).
Hope to serve you well as a member of Moonbeam Governance Guild!
Reason for the Vote:
For me this is a very straightforward vote, as it aims to help a member of the community that has mistakenly moved their funds. However, I have concerns on what should be done if such cases start to occur more often, as there is a human cost involved on terms of time and effort employed to proceed with the recovery. Perhaps on the future, a policy for retrievals could be estabilished, where it no only has to be approved by governance, but also where a fee could be charged on the amount recovered, in order to compensate the effort.
Reason for the Vote:
I vote in favor because this proposal tackles a key change for sustainability. Any chain that whishes to foster adoption and ecosystem development can benefit from having a recurrent mechanism for incentives. As such directing resources from the parachain auction reserve, which is not as nearly as expensive as it was when Moonbeam was launched and that it seems poised to become obsolete, seems a good idea and a well executed strategic move.
Reason for the Vote:
I vote in favor because the updated tackle important issues in the network, specially the reduction of the min gas fee in 4x to correctly accomodate and compensate the acceleration of CPU Time allowed in block production.
Reason for the Vote:
I vote in favor because proprosal #92 was indeed submitted in error, and the proposal must be invalidated to free up the submission deposit.
Reason for the Vote:
I vote in favor to proposal #95, as I agree to recover the funds lost by a user due to a failure in XCM transaction from Polkadot to Moonbeam.
Reason for the Vote:
I vote in favor to proposal #96 in agreement to the RT3041 hotfix as it deals with the important issue of fixing the Treasury spending flow issue. Overall, the post-RT3401 spending flow proccess seems more efficient and less burocratic, as it does not require locking of funds.
Reason for NOT VOTING:
Proposal #97 lacked a proper forum posting which is the procedure to be done when submitting a proposal. The forum post eventually was published, but on the very same day that AYE quorum was reached, then executing the proposal as it was fast tracked. As I was waiting for the forum post to properly assess and follow protocol, I was unable to participate in governance. As a side note, I would’ve voted YES given the forum post was published before the execution.
Reason for NOT VOTING:
Proposal #98 lacked a proper forum posting which is the procedure to be done when submitting a proposal. As I was waiting for the forum post to properly assess and follow protocol, I was unable to participate in governance. As a side note, I would’ve voted YES given the forum post was published before the execution.
Reason for voting AYE:
Proposal #99 is the continuation of both #97 and #98, which set up LAOS and EURC as XCM bridged tokens. The aim of proposal #99 is to promote both tokens to ERC-20 standard from just being standard pallet assets.
As also happened to both #97 and #98, #99 algo lacks a proper forum posting which is the procedure to be done when submitting a proposal. While the lack of proper procedure made me abstain from voting in the previous issues, I find that there is no more point now in abstainance since all of three are interconnected and #97/#98 have been approved by the community albeit the absence of a forum posting.
Reason for voting AYE:
Proposal #100 is a no brainer. Polkadex is no longer a parachain, so it’s XCM channels related to Moonbean have stopped working and must be closed.
Reason for voting AYE:
Proposal #101 aims to increase the burning of GLMR to 100% of transaction fees. This has been demeed feasible due to a study conducted with the Gauntlet team ([Ext]: Grant Program Forum Post Part 2 - Macroeconomics and Tokenomics) which found out that Moonbeam is able to sustain its costs with parachain auction slots solely by the yield captured via DOT Staking.
Even as increasing the burning rate from the current 80% to 100% is not really a huge policy change able to promote greater significative deflationary pressure, I find that it is healthy and so I support the initiative, which may pay results in the long run.
Reason for voting AYE:
Proposal #102 requires authorization for upgrading Moonbeam to RT3051. Good highligths are: 1) Returning overestimated fees on PoV computation at the end of transactions; 2) Updating XCM to V3 and ending support for XCM V2; 3) New fee policy that directs priority and substrate tips to block authors. I’m in agreement with these changes and the overral update.
== Referendum #103-#104-#105 == #103 - Proposal: Evolution of the Community Grant Program #104 - InvArch Proposal Open/Accept HRMP channel and Register Asset xcVARCH #105 - Reducing Moonbeam self bond to 500k GLMR
Reason for voting AYE:
Proposal #103 is suggesting changes to the Community Grants Program as its current committee’s term is coming to an end. The main changes are reducing the total seats from 9 to 5, extending the term from 6 months to an year and better structuring devrel and grantees management. As a grantee myself I appreciate the proposal and think it is going to improve the overall activity of the Grants Committee.
Proposal #104 wants to stablish a new HTMP channel with InvArch chain, allowing the transfer of GLMR and xcVARCH between the two chains. As the proposal brings more potential demand for GLMR and on-chain activity, I vote for AYE.
Proposal #105 wants to reduce Moonbeam self bond from 2M to 500K GLMR. It intends to reduce the entrance barrier for new collators on the network and enhance decentralization. I find the proposal worthy and aligned with the overall Moonbeam ethos.
Reason for voting:
Proposal #106 I found that the proposal was not sufficiently discussed and was eventually waiting for answers from some topics from the forum which did not happen in time before the approval. I’m not fond of overfunding Moonwell without a clear plan on which operations are going to be incentivized, specially considering that the emission of more rewards can result in more sell pressure on GLMR which is at all time lows.
Proposal #107 is about the upgrade to the RT3600 runtime. It’s main topics are supporting the migration of legacy assets to native ones and implementing previous approved governance topics, such as reducing moonbeam self-bond. I support the proposal.
Proposal #108 is about registering ETH, USDC, USDT & DAI as Snowbridge assets, in support of the overall transition form legacy to native assets. It makes perfectly sense and is a important step on my assessment. I support the proposal.
Hey all, my name is Rafael Castaneda, aka “CastaCrypto”.