This is DonOfDAOs Delegate Communication Thread. It will be updated periodically.
Wallet: 0xCE8Ab0464957EAB5635344A62FAb9Bf5a3FF8cA3
I voted FOR TMC’s recommendation as to not disrupt the TMC’s process flow and support their continued efforts. https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0xc37793b67f39a6af9e9434003205b1d9b67dd6f75638329045257be823da4f18/votes
Rationale for Abstaining on Proposal: [NON-CONSTITUTIONAL] Arbitrum Onboarding V2: A Governance Bootcamp
This comment is not representative of my position as a founder of Event Horizon and does not encompass the entire Event Horizon community nor can it predict how the community may meta-govern this proposal should it come to a vote.
I have chosen to abstain from voting on [NON-CONSTITUTIONAL] Arbitrum Onboarding V2: A Governance Bootcamp as to avoid any potential conflicts perceived between my work in voter inclusion at Event Horizon. However, I would personally be willing to meet with the working group (at no cost) to help facilitate this initiative in its current state should it pass, or in iteration should it not.
I voted FOR AIP: Timeboost + Nova Fee Sweep :
As a newly active delegate, I’ll preface this response by saying much of my response and questioning is for my own education, rather than critique:
- I support added revenue for the DAO, but is there any notion of the expected amount of revenue to be generated?
- Does this system, theoretically and if used substantially, run the risk of taking precedence over all non-express transactions thereby forcing all txs to be handled within the express lane and creating a bidding war for processing / high effective tx fee?
- I echo some of the other delegates in advocating for the separation of completely disparate proposal actions in the future. Nova fee sweep seems far more simple and generally agreeable. To package a fairly straightforward, non-experimental, and broadly agreed upon action with an experimental, complex, chain-level alternation seems to only muddy things.
- Contrary to some general delegate commentary, I do generally support the delay of non-express lane transactions. While it doubles tx time, I don’t believe 200ms is a sum of time appreciable to the average retail user. And, it is certainly not a driving factor in a retail user’s choice of chain. Personally, I believe transaction speed between chains being a marketable advantage is converging on zero as all chains approach speeds seemingly instantaneous to the average user. At a certain point, being milliseconds faster than the next chain simply doesn’t matter.
This being said, I will vote FOR this proposal in support of OCL, added revenue for the DAO, and lack of strong concern to justify not experimenting with this solution.
I will ABSTAIN from [NON-CONSTITUTIONAL] Arbitrum Audit Program:
As a builder in the space myself who had to complete security compliance and benefitted from support from DAO initiatives, I can strongly emphasize A. the importance of proper security auditing B. the significance of supporting early ventures in making it happen. The capacity of a new protocol or project to internally fund all security requirements is not a mark of its potential value to the ecosystem. Many projects simply don’t have the funds to establish compliance and are left unable to proceed forward. Without supporting these ventures, Arbitrum as an ecosystem would likely lose a tremendous amount of potential value.
That said, I am unsure why the conversion of ARB to USDC has to occur immediately and place downward pressure on the value of the ARB token (unless there is an OTC process I am missing). I imagine it may be to keep the total number of potentially supported projects at the rounded 100. However, candidly, 100 seems excessive to begin with, so in the event of downside price action, I’m not sure fewer than 100 would be a tragedy. And, given price action is bi-directional and markets are fairly compressed at present, we may actually see an expansion in token value and room for even more than 100 projects. Ultimately, I believe periodic (ideally OTC) swaps would be preferable. For this reason, I will ABSTAIN from this proposal. Should the community support it broadly, I would happily see it pass. However, should it not pass and need revision the above would be my suggestion.
I am voting FOR this GMC's Preferred Choices for 7,500 ETH RFP - #53 by DonOfDAOs :
I’m generally in favor of the productive mobilization of treasury assets. While the specific allocations and chain source can be debated infinitely, I see this as a first step in the right direction. Refinement, fine tuning and adjustments can be made with future proposals, but it’s important to get yield off 0% as a first motion.
I am voting FOR [Non-constitutional][RFC] ARB Incentives: User Acquisition for dApps & Protocols at temperature check:
From my experience as a builder in the space, I can emphasize the value in not just capital, but support in exposure and amplification. Further, the emphasis on off-chain / web 2 marketing is drastically need. I would actually be more in favor of a proposal that allocated smaller sums of funding as a trial and really proved its merit through the assistance provided. A notion of ‘how far can we take $50,000’ vs starting with $150,000. With a more constrained budget focused on optimization and efficiency there could always be room to either expand the budgets for the cohort down the line or add seats for more ventures. That said, I will vote FOR this proposal during the temp check and would be open to a downsizing of the budget before onchain voting.
I voted FOR TMC Proposed Allocations V2 -- ARB Strategy and TMC Proposed Allocations V2 -- Stablecoin Strategy
Broadly, I support yield production on treasury held assets. I’ve worked with a majority of the parties involved and can vouch for their strong competency. I do hold reservation to the price impact of selling 15M ARB, but assuming OTC this risk can be offset. Further, I would be interested in seeing the yield proceed go toward token buyback and should the program end fully, a repurchase of ARB with the stable balance.
STEP 2 STEP 2 Committee Preferred Allocations
Vote Decision: FOR
Rational: I support the committee and trust the rigor they assumed when selecting from a clearly broad enough sampling of options. I do want to ask if there is any publicly available data on why each asset was selected, why others were not, and/or the rubric by which they were assessed.
DRIP Snapshot Proposal – DeFi Renaissance Incentive Program (DRIP)
Commentary Update: DeFi Renaissance Incentive Program (DRIP) - #11 by DonOfDAOs
Vote Decision: FOR
Rationale: I vote FOR this snapshot vote as I appreciate the initiative and its more targeted approach to driving impact in the space. That said, I would like to see payment scaling based on KPI targets along the rubric of metrics desired. e.g. tranche grants as output metrics are met. I also am unsure why the full 80M must be carved out immediately. This to be a standard practice in the ecosystem that we set aside very large chunks for large scale initiatives at onset. I often feel this creates lock-in which can limit flexibility or program modification down the line.
Watch Dog – The Watchdog: Arbitrum DAO's Grant Misuse Bounty Program - #109 by danielo
Vote Decision: FOR
Rationale: This is intuitively an ecosystem-positive program
Commentary on: Huddle01 [Non-Constitutional] Let's get our huddles (aka. video calls) in order - #36 by DonOfDAOs
I am in favor of experimentation here. Much of the supportive commentary to this point has been strong, so without rehashing I broadly agree with many of the delegates above.
An operational note not yet referenced:
– Given IPFS storage, we need to be cognizant of the limited ability to remove recordings from publication. Because of this, we should take steps such as structuring a standardized meeting kick-off process inclusive of notes such as “for those who don’t want to be recorded, please turn your cameras off now” – this is something Sinkas does regularly on the current meetings, and in an IPFS structure I’d say should be standard policy. There are likely other privacy and best practice considerations which would warrant a short discussion. Nothing critically blocking, but simply worth thought.
Then there are more standard meeting setup processes which would address some of the concerns of friction, barrier to entry, risk of performance. Simply:
- Begin testing huddle on ‘lower significance’ calls initially. So a structure for which types of calls early testing will start on and which would maintain the current google setup would be helpful.
- Ensure that there is a backup google meet link added into the description of invites testing huddle. At any point, the meeting organizer can route the audience toward the back up link.
With these two points added, and consideration for meeting recording processes, I see benefits in testing this then scaling up if it is well received.