[Social] [EP2.2.5] Selection of an ENS endowment fund manager

[nick.eth]

@slobo.eth

This amounts to less than a year worth of runway. Until there is at least 2 years of stables in the treasury I cannot in good conscious put ENS Labs and thus ENS at risk. Therefore, my number one choice is None of the Above.

To be clear, voting for any of these proposals is not incompatible with that. All of them will see at least the earned income (~12k eth) sold for USDC, and the DAO can choose to change how the unearned income is handled at any time. We can also choose how much is set aside as non-endowment funds.

I’ve been intending to open this conversation myself after the vote - about whether we should change how unearned income is accounted for, and move much more of it into stablecoins, giving up some upside for more assurance of ENS’s long-term viability. I think having some kind of treasury management is practically a requirement for enacting that, though.

[accessor.eth]

I believe that management is an integral part of any project with over $1M in holdings and continuous income. It’s clear that the treasury holds well beyond that amount. We should have a management plan. I wholeheartedly agree with that.

As much as we have instilled this sort of a shared new age ideology or proxy business model as a DAO per se, and regardless of any terminology or approach to collective decisions this is easier described as a ‘community ran entity’. When it comes down to the nitty gritty, one of the prominent accolades to be recognized for is self-governed internal financial management as a DAO.

To me – a DAO in web 3 should be their own service provider, developer, social management, media source etc…and a solid team that make strategic decisions about DAO financial positions of their own domain, internally.

Although the output goal is the product, having a strong core of financially focused working group members speaks numbers. I don’t want anyone who is outside of the DAO to manage any of the treasury.

Know finance or no finance. Know when or non win.

It comes with the package in crypto. There are plenty of people who have the best interest in the progress of this project to achieve greater greats. If it takes getting on a voice call or video call from dinner time until sunrise, then so be it. As a DAO putting out a project along with internally managing it’s finances is what would make an even stronger success story to be proud of. I would like to see ENS DAO be creme de la creme of all product initiative DAOs. In my view, financial responsibility should sit on the DAOS shoulders as a mainpiece that coincides with the deliverable product.

I would be totally fine if (some) money was lost on behalf of the strategy decided within. I would be extremely upset if a fund manager outside to the DAO would lose funds or not profit up to the projected expectations.

ENS is unique and has multiple perspectives of business methodology.

• ENS (the product) (income aggregator)
• ENS Labs (a mechanism to specifically fund developers)
• Open-Source (allows contribution of all changes that would enhance deliverable)
• DAO (encapsulates decision processing, organizational function spanning the ecosystem)

Functional layers of ENS. Ecosystem. (ref. fig.1)

• ENS
• The Governance of the DAO as a whole.
• Working groups within the DAO
• Stewards over their respective Working Group
• Onboarded Members
• Projects Building on ENS
• Community Dedication

This presents a linear funding self sufficiency mechanism to perpetuate ENS existence, sustainability and growth by registration income free and clear of outside contributors.

Adding a fund-manager introduces a extremely high level of risk that has potential to compromise the every aspect of this project. (ref. fig. 2)

As. you can see in my ‘encapsulation diagram of inherent risk’

All ENS funded projects extend outward towards the community while the community interaction influences the projects being developed and generally inherits almost zero risk or chance of any monetary loss.

As ENS becomes reliant on the fund manager entity-- both become one in the same in terms of reliancy, so they exist in the same encapsulation.note Except that the fund manager has essentially zero-risk of loss due to poor performance—without the loss of being compensated for the opposite outcome of a high performing yield aggregating successful strategy.

A complete loss of funds would compromise the DAO, Treasury, Stewards, working groups and ultimately the ability to further fund projects developing ENS. The existence of ENS would be less affected as it has become a permanent contract on the Ethereum Blockchain and would continue to exist even without guidance from the DAO or ENS Labs. Adding an external fund management entity is too much of a risk on the project. Loss of funds happens far too often in a myriad of ways. Risk reduction is extremely important. Adding new contracts to the mix isn’t favorable when comparing risk off exploitation vs reward by chance. This isn’t meant to discredit any contract writers in any way.

That basically I have to contribute towards the initiative.

Sustainability, Management, Responsibility until the core of ENS projects is complete needs focus first. We don’t have any data on income with the most anticipated feature of ENS–the subdomains. This must wait or be managed internally or the whole project assumes great risk.

[elisafly]

Hi @Avsa, a few comments:

On the other hand I know, use and know lots of people who use Safe. That already tells me something about the maturity of both codebases.

The infrastructure comparison that is being voted on is “Safe + Zodiac” with “Safe + Enzyme”. Safe + Enzyme has a much more battle tested history than Safe + Zodiac when it comes to trustless asset management. Safe on its own is just a wallet like metamask and does not solve the problem of trustless asset management.

Additionally, and thanks to the graph protocol underpinning our data pipelines, it is easy to automate + query reports at any point and time in history with Enzyme.

I’ve heard about Melon port from the old days, but never personally used and don’t know anyone who uses it so I have no experience.

Two of the largest insurance protocols use Enzyme to manage their assets trustlessly:

• Nexus mutual with > 15000 ETH
• Unslashed finance with > 17000 ETH

We’ve provided these and more references to the stewards.

That already tells me something about the maturity of both codebases.

Again, I’d like to see you comparing like for like here (Zodiac’s trustless asset management contracts,with Enzyme’s).

• Audit report history here.

• The Enzyme Council is composed of smart contract auditors. Happy to connect you with any of the auditors or council members if you would like to dig deeper into anything technical.

[Griff]

My 7 tweet summary and request for more opinions:

[claberus]

Hi @nick.eth and @AvsA,

This is claberus, Karpatkey’s cofounder.

I noticed the discussion revolves around the safest smart contract infrastructure for non-custodial fund management. This is the wrong problem to focus on, as this has been resolved a long time ago with open-source tooling like Enzyme and Zodiac. It’s natural though, because as engineers we tend to focus on tools and not on Finance.

I wish the discussion were focused on the experience and rationale of decision-making for the investments and the processes, protocols and infrastructure for risk management. The success or failure of the enDAOment will probably be determined by these factors.

[elisafly]

Avantguarde is taking more risk using centralized services like Maple and Goldfinch to earn larger returns then what defi can normally give.

Slight clarification here. Asset Management is all about understanding risk/rewards and allocating accordingly. This is why we allocate to AAVE and Compound in large size, whilst keeping Maple/Goldfinch sizings appropriate for the risk they represent to the portfolio as a whole. We believe that we understand those risks better than most because of the diligence we put into the protocols as part of a) our investment process and b) when our engineering team integrates protocols like Maple/Goldfinch into Enzyme.

Karpetkey have made several references to discredit protocols like Maple and Goldfinch as being too risky for ENS in threads like this.

We totally disagree with their arguments. Our response is summarised here.

[SpikeWatanabe.eth]

@elisafly

Asset Management is all about understanding risk/rewards and allocating accordingly. This is why we allocate to AAVE and Compound in large size, whilst keeping Maple/Goldfinch sizings appropriate for the risk they represent to the portfolio as a whole.

I just can’t help myself but wonder why allocate any amount to any other protocol than AAVE or Compound? In case of ENS the priority is low risk conservative strategy. I appreciate the argument that as “most efficient” managers you would want to capture that “long tail of returns” to smooth out that risk/rewards curve. I’m thinking that additional rewards in this case would be so marginal, so allocating to Maple/Goldfinch almost feels like a disproportionate cost to the whole project, if you assume that “ENS social perception” is also a cost.

EDIT: I did read the Twit thread with summarised response

[antoinescalia]

Hi, this is Antoine from Cryptio.

Although it wasn’t part of the original RFP, we noticed that Llama and Karpetkey included broader DAO reporting services that extend beyond just the treasury being managed.

We’ve been working with Avantgarde on combining and automating this functionality and we’d love to complement the Avantgarde proposal by partnering with them to provide this reporting functionality.

Here’s the proposal of how Cryptio would work for ENS.

I have also recorded a short video going through the solution:

https://www.youtube.com/watch?v=xhpzWlkNZbQ

What does this mean:

• We’ll sign ENS up to Cryptio and ensure that all DAO transactions are being correctly tagged
• We’ll give the community access to the Cryptio account so that they can transparently view transactions going in and out with the correct tagging
• We’ll generate oversight reports backed by on-chain data for the DAO with full transparency to the community

Our Edge:

• Enterprise-grade accuracy & completeness brought to ENS DAO: Our data is more reliable and accurate than chain explorers. This is because we have developed proprietary indexers specifically for accounting and reporting. We conduct daily sanity checks to ensure the data is complete and accurate. Nothing is more important than being able to trust the transaction records.

• Track record with 250+ crypto enterprises & DAOs: We are working with the likes of Metamask, Aave, 1inch, DeFiSaver and IndexCoop, and 250 other crypto enterprises & DAOs.

• Dedicated team & expertise: ENS will have a seamless onboarding process with our dedicated team, and community members will have access to the platform. During the implementation, we would work with the team to customize the dashboard and reports for the needs of the DAO. We also have 30+ years of combined accounting experience to help advise on best practices for reporting.

Our industry needs this and we’re delighted to support Avantgarde and ENS with this as part of our own product roadmap development.

Who Is Cryptio?

For those of you who don’t know Cryptio, we’ve been in the crypto accounting industry for five years and are powering the reporting for 250+ Crypto projects and businesses such as Metamask, Aave, IndexCoop, and 1inch.

We’ve been building out proprietary on-chain data infrastructure to guarantee the completeness and accuracy of data. Our indexers have been battle-tested over the last 5 years with top crypto enterprises.

[AvsA]

@elisafly

The infrastructure comparison that is being voted on is “ Safe + Zodiac ” with “ Safe + Enzyme ”. Safe + Enzyme has a much more battle tested history than Safe + Zodiac when it comes to trustless asset management.

Thanks for that clarification Mona. It’s a very important point. As I said, I’m still open to reconsidering my vote until the deadline.

[Eek637]

Thanks for your reply. I think you’re making two arguments here. I’ll paraphrase and respond to each:

Argument 1: The incremental reward for allocating to higher-risk protocols is not worth the economic downside if those allocations result in a loss, why not just allocate all to the blue-chip, safest lending protocols?

This RFP mandated an annual return of 4m USDC. Rates on Compound and Aave (which we love, btw) are low enough that we’d need to allocate about $500m USDC to that strategy to meet the RFP’s requirement. You could also argue that such a large allocation would drive rates down further so the number might actually be bigger than that. Additionally, that strategy creates concentration risk. Aave and Compound have a solid track record, yes. But do we want to put a quarter of a billion dollars into each? Probably not. Instead, we can spread out our investments over a wide variety of protocols, and size them according to the risk we believe each presents along a number of axes, including financial and idiosyncratic risk, smart contract risk, etc. This diversification will also increase returns - $1m allocated to a Maple pool returning 15% contributes a lot more to our 4m USDC/yr goal than the same $1m allocated to Compound.

Argument 2: Protocols such as Maple and Goldfinch are centralized, and that’s against the ENS ethos.

I disagree here! It’s true that these protocols use a delegate system to allocate capital, and that could potentially be seen as a point of centralization. If you dig deeper though, they are actually enabling efficient capital formation, allocation, and distribution to real world use cases. Basically, using the best assets of a distributed ledger in combination with traditional credit underwriting processes to expand the potential market for both lenders and borrowers. In my opinion, the “maple is not decentralized” argument is misunderstanding the functionality that the protocol actually provides and focusing on one small part of the mechanism (the delegate).

[SpikeWatanabe.eth]

fair enough, what a great response! I like that

@Eek637

This RFP mandated an annual return of 4m USDC. Rates on Compound and Aave (which we love, btw) are low enough that we’d need to allocate about $500m USDC to that strategy to meet the RFP’s requirement.

@Eek637

I disagree here!

Actually I never said that I personally have anything against those “entities”, it was more of case “know your target audience” and elaborate to them your arguments. I can see, that there was some like a pushback in that particular “pressure point”, so I figured I’d raise the question.

Maybe things are tiny bit more clear for everyone like this. Thanks for detailed response.

[simona_pop]

Steward’s View - simona.eth

As we know, this has probably been one of the most important MG working group endeavours to date and all three MG stewards have spent a lot of time getting the RFP process together and reviewing submissions. We also reviewed references put forward by the projects and conducted calls with said references to further ensure we had as complete of a perspective as possible in drafting this shortlist.

As @nick.eth mentioned, this is a short note summarising my personal view on the finalists as an MG steward involved in the process.

*This post represents my personal views, not those of the WG or the DAO.

Avantgarde

Avantgarde and Enzyme, prev Melonport, are the most established of the shortlist and their track record is testament of that. The team is solid, their code thoroughly audited via multiple audits and their a safe approach is in line with the ENS profile.

The option to withdraw or change strategy at any point also means there is a high degree of flexibility in being able to adapt dynamics going forward which I find very reassuring and in line with navigating our climate.

Having discussed genuinely meaningful reporting (even though not required in the RFP) and its importance with the team, they are agreed to offer a level of reporting that was deemed valuable by the WG.

Karpatkey

As echoed by @nick.eth, Karpatkey were the ones to include in their proposal a broader financial reporting piece which includes forecasting and analysis of financial impact of specific EPs. The reporting piece is something I have personally felt missing in a lot of DAO treasury matters and feel it is important for transparency, timely decisions and an ongoing finger on the pulse of treasury health or threats to said health.

They most notably manage Gnosis’s treasury which is probably one of the best performing treasuries in the DAO space. This is not because of any wild movements but specifically due, I believe, to Karpatkey’s cautious approach to earning yield via liquidity provision on low-slippage pools.

Zodiac, the Gnosis safe plugin proposed is in line with the flexible control the DAO can have regarding the operations the fund manager is allowed to execute on behalf of the DAO.

Llama

As already mentioned, Llama’s proposal involves investment negotiation post-acceptance so the level of detail and ability to compare with other proposals was slightly more difficult. The onchain management piece via DAO vote does mean less timely control on critical decisions and would require high levels of speed in voting process. As a DAO veteran at this point, I am more than familiar with the interesting aspects of that piece in governance…

The fee aspect was also slightly difficult to compare with the other two finalists but their min annual fee is $500k USD - as you can find in @nick.eth’s note, some forecasting does make that a more cost effective proposition in the long terms based on eventual size and certain yield thresholds.

My vote

I will be voting for Karpatkey. As mentioned above, I believe their great work with Gnosis, my personal familiarity with Safe and the strong reporting piece are all part of that decision. Second option would be Avantgarde.

[accessor.eth]

@claberus

I noticed the discussion revolves around the safest smart contract infrastructure for non-custodial fund management. This is the wrong problem to focus on, as this has been resolved a long time ago with open-source tooling like Enzyme and Zodiac. It’s natural though, because as engineers we tend to focus on tools and not on Finance.

Completely disagree there has been well over two dozen incidents in the past 30 days of funds being stolen totalling over $800 million dollars. At least 13 of which involve exploited vulns in smart contracts. Smart contract bug hunters are out in full force and it grows by the day. What they decide to do with in potential exploits is reliant on them.

We can’t pretend that the possibility doesn’t exist and should be factored in accordingly to the same degree of each proposal.

[MakerMan]

@nick.eth

I want to emphasise that the goal of the endowment is not to secure a short to medium term runway for ENS - we already have that, and registration revenue continues to exceed our expenses.

The point of the endowment is to ensure ENS’s long term sustainability, even in the face of an extended recession and reduced registration/renewal revenue.

Delegate Perspective - MakerMan.eth

My own views as an independent ENS delegate agent.

@slobo.eth

The treasury has 2.5m in stables, as of Nov 17, 2022 per tally.

As a former businessman I can say that having cash for A MINIMUM of 1 year is a critical requirement. Given that most investments SHOULD have 3-10 year time horizons I would want to make sure I had 3 years operational runway with a 20% overhead for unforeseen expenses.

This ENDAOment move is premature at this time and is potentially hazardous.

@slobo.eth

Eth is volatile.

Revenue is volatile.

Stables are stable.

There is a serious risk to the organization should incoming ETH not be converted to stables particularly if the crypto markets take another 50-75% price hit.

The above is why I voted:

1. None of the Above
2. Avantegarde
3. Llama
4. Karpatkey

[elisafly]

Hey @simona_pop
I’m re-surfacing what I shared on Avsa’s point here.

my personal familiarity with Safe

The comparison should be between Zodiac + Enzyme because we are both proposing to use Safe together with those two.

the strong reporting piece
I would like invite you to a demo of our reporting capability along with anyone else who like. Thanks to the graph protocol underpinning our data pipelines, it is easy to automate + query reports at any point and time in history with Enzyme. None of the other applicants have this capability and I think it’s incredibly important to be able to do this easily. We’ve dedicated years building this reporting capability out for exactly this purpose.

[MakerMan]

One other point that hit me as a long time ‘investor’ in the crypto space.

Isn’t it a general rule in crypto to never EVER put all your investments into a single basket.

This Treasury Management proposal focusing on a single manager breaks the biggest rule of investing and crypto risk management.

If this passes I honestly would urge this treasury money be spread around with all 3 of the managers than lopping it all into one for the above single reason.

I stand distinctly against this for the reasons in my posts.
It is premature and presents significant risk.

[dame]

Based on the proposals, feedback, forum discussions, and more, I’ve selected the following as my ranking:

1. Llama
2. Karpatkey
3. Avantgarde
4. None of the Above

Ultimately I decided to prioritize experience with other major DAOs/protocols. I do not believe Llama’s 1% fee is a big deal in the grand scheme of things, and I think concerns about frequency of on-chain votes are exaggerated.

All this being said, I think the Stewards did an incredibly solid job of narrowing down our options to these three. Because of the Stewards’ efforts, I believe we’ll be in good hands regardless of which one ultimately wins. Thank you to the Stewards for all your work on this and for sharing your perspectives on the DAO forum. And thank you to the community for voicing concerns, questions, and suggestions. Go ENS!

[EvanVanNess]

am i the only one worried that snapshot’s display of the votes is likely to influence actual votes? [yes i understand that it shouldn’t matter]

it’s a relatively close vote right now, but ranked choice in snapshot is…confusing.

[elisafly]

I’m pretty worreid about that too right now…for the last 40min its been completely off showing “none of the above” and “avantgarde” with zero votes

[AvsA]

@claberus

I noticed the discussion revolves around the safest smart contract infrastructure for non-custodial fund management. This is the wrong problem to focus on, as this has been resolved a long time ago with open-source tooling like Enzyme and Zodiac. It’s natural though, because as engineers we tend to focus on tools and not on Finance.

I disagree. After the proposal passes, if Karpatkey wins but we want change the allocation to also have exposure to say, Maple or Goldfinch, we could ask you to do so. But if we decide on the wrong tech stack, changing later is a lot harder.

@EvanVanNess

am i the only one worried that snapshot’s display of the votes is likely to influence actual votes? [yes i understand that it shouldn’t matter] it’s a relatively close vote right now, but ranked choice in snapshot is…confusing.

This is very true. I am trying to help people visualize Ranked Choice better on this twitter thread: https://twitter.com/avsa/status/1593626868439289858?s=61&t=BcifbEttoK-1Ws5pSCiCIg

I do wish snapshot changed its visualization as it’s definitely misleading.