Name (organization or individual): Individual

• Seamus McNab from Mycelium.

Wallet Address or ENS: 0xD35629A2b7fB9f232fda6C29b72035A7dbaFA3C1

Tally Profile URL: https://www.tally.xyz/profile/0xd35629a2b7fb9f232fda6c29b72035a7dbafa3c1

What area are you most interested in contributing to?

• DeFi development on Arbitrum
• Supporting Infrastructure

Please share your stance on overall goals for the DAO:

The Arbitrum DAO should be growth oriented in choosing to build and work with growth partners that are going to bring the next trillions of transactions to the Arbitrum layer and scale the stack into a broader consumer market. Liquidity mining should only occur in extremely targeted ways, if at all. Arbitrum DAO will only ever have the tokens that it has now (+ any potential future inflation) and should therefore spend the tokens as wisely as possible.

Arbitrum already has a product that people care about. Better plays in my eyes would be to provide grants to attract new customers that will further scale Arbitrum (e.g. provide a grant to attract somebody like the NYSE to deploy on an L3.) I would also advise that any liquidity mining that does occur should also implement some vesting mechanism on earned Arbitrum, with a way to delegate and vote with vesting ARB.

Sample Voting Issue 1

How would you vote? Against - but not due to centralisation.

What amendments would you make to the proposal if any? If the service is worthwhile, pay for it rather than risking treasury to generate yield that pays for it. With the team in that proposal planning on interacting with any other contracts other than Uniswap or Aave that haven’t undergone serious battle-hardening and vetting there is a real risk of smart contract failure. In my view it’s not worth risking ARB treasury for community analytics which often are created anyway if there’s traction with the project. If analytics are in demand by the community then direct funding with ARB is a better path without posing any significant treasury risk.

How would you approach the tradeoff between centralization of authority and the ability to get things done? The biggest threat to Arbitrum that I see is not being able to move fast enough to provide support to grow and maintain market share. With this view, I believe that centralisation of authority is fine. This is caveated with a requirement for absolute transparency and clear oversight from an expert committee. DAO governance can often slow entities down and it’s important that Arbitrum remains fast. I think another key piece is to ensure that anywhere centralisation exists, there is a dispute / eject protocol so that should a group like this start misbehaving, ultimately there is oversight by the DAO / community. Let’s give autonomy to people to create action, but ensure that misbehaving is punished.

Sample Voting Issue 2

Split Reimbursement

A partial reimbursement should be paid for by the DAO depending on the economic strength of the project. Both because FEI RARI and its token-holder community should value it’s customers and wish for them to return to the protocol and also because it is fair to do with a significant treasury and also important to maintain brand.

With that being said, customers are using speculative DeFi products and should be comfortable taking the risk that all funds could be lost from deposits as emerging technology can be risky and difficult to build. If the code is fully audited and there exists the appropriate bug bounties and avenues for blackhats to become whitehats, then this team has done basically as much as possible.

Smart contract developers and teams that have gone to the length of getting top tier firms to audit their code for vulnerabilities should not be forced to pay out in full for protocol exploits. These audits are a large cost, as are the payouts. It’s important that these teams retain runway in order to build the future of the decentralised financial system.

Languages I speak and write: English

Disclosure of Conflict(s) of Interest: Builder at Mycelium within the DeFi and Infrastructure space.