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

Hey, I didn’t mean to put a negative spin on this, it was just an observation and I also try to be as objective as possible. I’m a bit of social media manic myself, today most of the cool stuff on CT and such, otherwise how do you stay informed. So I just noticed how Avantgarde was hugging every twit and every relevant post they saw, providing feedback and defending their position. I felt like they are very “present”. Also keep in mind that this is my subjective opinion, everyone is different.

Good morning!

No investment is risk-free. If it were, it would yield nothing.

Our approach to portfolio management is not to avoid risk entirely, but to focus on making sure we thoroughly understand the risks (and rewards) of a given investment through extensive research and diligence. We look to understand for example, how these protocols work, where, how often, and to what extent can things go wrong and what does the protocol stand to gain if things go according to plan? I spoke about this at length in @Griff 's Twitter space on Saturday.

Allocating an appropriately-sized portion of a portfolio to strong risk-adjusted opportunities is how an investment strategy generates returns. Sizing riskier positions appropriately also means if things don’t go to plan, the overall portfolio can still survive and even thrive. Maple and Goldfinch do indeed represent relatively higher risks than e.g. Compound and Aave, but we believe the proposed sizing in our model portfolio is appropriate for the return potential

Now, on to specific claims made:

Lending funds to Alameda in July 2022, after the Luna collapse, when it was likely already insolvent. The payment was due for January 2023, but for some reason, it was repaid fully in advance.

This is a red herring. Maple as a protocol had no outstanding direct exposure to Alameda at the time of its bankruptcy and lenders suffered no losses due to an Alameda default. Indeed, the pace of lending to Alameda had slowed, and lending was stopped from their single-borrower pool based on delegates’ concerns over the degradation of Alameda’s financial statements prior to the Luna collapse.

For those that are interested in listening to Maven11 and Orthogonal’s credit managers describe the process, there was a great webinar last week that walked through the Alameda collapse from their perspective.

  • The last loan to Alameda from the Orthogonal USDC pool was a 90-day maturity issued on 17 Feb 2022 that was repaid in its entirety. This can be viewed in the Maple app here and verified on chain.
  • The last loan to Alameda from the Alameda Single Borrower pool was a 90-day maturity issued on 21 May 2022 that was repaid in its entirety. This can be viewed in the Maple app here and verified on chain.
  • The last Maple loan to Alameda was issued from the Maven 11 pool. It was a 90-day maturity issued on 4 June 2022 that was repaid in its entirety. This can be viewed on the Maple app here and verified on chain.

Open loans on crypto hedge fund Wintermute which was hacked and had funds on FTX

Open loans with crypto hedge fund Folkvang, partly owned by FTX

Two points here.

First, Wintermute and Folkvang, like every other market maker in the space, have funds trapped on FTX. Wintermute did have their DeFi operations hacked. However, thanks to proper counterparty management, none of the above have a material impact on the companies’ balance sheets and none resulted in losses to lenders. Notably, Folkvang was the first market maker to repay all their outstanding debt to counterparties to alleviate any concerns.

Second, the equity investment you’re describing in Folkvang was made by Alameda, not FTX. Alameda made equity investments in dozens (hundreds?) of crypto-native companies. Their investment in Folkvang was small as a percentage of the company’s total equity and came with no strings attached in terms of volume requirements on FTX itself (see first point regarding counterparty risk management).

Recently liquidated Crypto hedge fund Babel was using customer funds to trade.

From the lender’s perspective, the total return in the Orthogonal USDC pool since inception is 5.96% inclusive of the Babel default loss (before recovery), and 2.1% YTD as of Sep 2022. These numbers are exclusive of MPL rewards.

Babel suffered a material loss caused by poor option hedging strategy that went against their book of assets and subsequently caused liquidity issues. This ultimately forced the firm to freeze assets and suspend normal operations. Orthogonal proactively issued a notice of default due to their inability to continue normal business operations, which was a breach of the Master Loan Agreement.

Upon default, Orthogonal bolstered the Pool Cover with an additional $1MM of capital to insure an adequate buffer for future and outstanding loans.The Maple Foundation, on behalf of the pool, has continued pursuing off-chain recovery with debtors and other creditors under New York Law.

Orthogonal Trading borrowed $36MM from Maven 11

Orthogonal Credit is a separate operational team from Orthogonal Trading. Orthogonal Trading is a well-established market making firm with robust financials and solid track record. Orthogonal Credit is a dedicated team to the credit operation on Maple Finance with deep experience in loan origination, risk management and capital markets. Orthogonal Credit is able to leverage Orthogonal Trading’s subject matter expertise in crypto market marking to enhance their risk management thesis. Importantly, Orthogonal Credit never lends to Orthogonal Trading from its Maple pool. And the beauty of the blockchain is that this is observable in real time.

Borrower prepayment of loans into the Maven11 pool means that Orthogonal currently makes up a large portion of the debt outstanding. To alleviate this imbalance, Orthogonal has started early prepayment of their loans with another 10m USDC to be repaid early over the coming weeks.

Most other borrowers are not googlable; many are likely part of an opaque legal engineering structure from other crypto hedge funds.

This is also a red herring and an unfounded speculation. Although delegates take reputational risk into consideration as part of their DD process, whether a borrower is discoverable by the general public has no impact on their credit-worthiness.

Goldfinch lends funds to consumers in developing countries. There is the question of not if, but when these countries are going to default on their debts dragging down the whole market. Again.

It is true that Goldfinch borrower pools have exposure to developing economies. This exposure is diversified across many countries and is fully collateralized at the individual loan level. Defaults at the loan level, the sovereign level, the pool level - all possible! But Goldfinch’s diversified nature, as well as our portfolio’s diversified nature, mean that none of those hypothetical defaults would have a material impact on the Endowment.

Maple, as a lending platform, should be neutral from pool delegates. Instead, they support them, likely because they are also investors. This aspect is risky and I hope Maple will change it.

I’m not sure I quite understand this point, but assuming you mean that Maple should function without pool delegates, I disagree entirely. Maple, at its core (in my opinion), is a coordination and incentive alignment platform. Lenders’ incentives align with delegates’ incentives align with the protocol’s incentives. Lenders provide capital, delegates provide first-loss capital and underwriting services, and the protocol provides the platform. Without the delegate’s underwriting services, there would be no way to meaningfully evaluate borrower risk and the platform would cease to function.

Implicit in the “we should get rid of pool delegates” argument is the idea that these types of risks can be managed purely by on-chain or algorithmic systems. I would argue that while this is a worthy goal, market structure complexity means that it’s currently not a feasible one. Tools such as Credora, which gives visibility into a borrower’s assets and credit worthiness in real time, are just that - tools (and good ones!). They enable and empower human decision-making. In the case of Maple’s current roster of pool delegates, that decision-making is also informed by decades of risk management experience, such that delegates are able to recognize “another one of those” (cribbing from Ray Dalio, apologies).

6 Likes

i starred both of y’all’s posts because I appreciate the vigorous debate!

3 Likes

Hi all,

Nic Munoz-McDonald here. For context: I’m a member of Enzyme’s Technical Council, an auditor that’s worked on both Enzyme and Safe over the years, and a fan of Zodiac. I’ve been following the discussion, and want to clarify some points.

Speaking from a smart contract security perspective, there are significant differences in Karpatkey’s and Enzyme’s approaches. The Enzyme approach is characterized by two principles: “defense in depth” and “smart contract controls wherever possible”. To that end, Enzyme takes a more holistic approach to security than Karpatkey: which implements controls at the individual transaction level.

I’d actually agree with an even stronger statement: there’s no such thing as non-custodial fund management without smart contract controls at the overarching fund level. Directly transferring out assets is far from the only way to siphon value out of a fund. As a simple example, a dishonest fund operator could make AMM trades with excessive slippage. Naively, the Zodiac Roles Modifier can protect against this just fine: you can restrict these calls to using a max slippage parameter below a given threshold. However, that doesn’t truly solve the problem: the fund operator can perform as many max slippage trades as they like. Each individual trade conforms to the smart contract controls in place, but cumulatively they can drain the fund. Contrastingly, Enzyme’s solution takes this into account (protocol/contracts/release/extensions/policy-manager/policies/asset-managers/CumulativeSlippageTolerancePolicy.sol at v4 · enzymefinance/protocol · GitHub). While seemingly less flexible, Enzyme’s policy hook based architecture can provide more expressive and powerful smart contract based controls.

Integrating a protocol doesn’t stop at whitelisting its entry points. Something as seemingly simple as assessing the value of LP shares you receive from an AMM, is fraught with pitfalls and edge cases that can snowball into vulnerabilities. The flexibility of the Zodiac Roles Modifier fuels very large hidden costs: every integration multiplies the attack surface. With Karpatkey, it is not clear to me who bears the cost of auditing these configurations. With Enzyme, each integration has been vetted by the core development team—who always have a direct line of communication to the protocols’ respective teams—as well as 3rd party audits. All paid for by Enzyme.

All these are simply part of the day to day operations of the Enzyme Technical Council, and have been since its inception in 2019. Honestly, I’ve been called into too many war rooms alongside fellow Enzyme Technical Council members ChainSecurity (https://chainsecurity.com/) to take this accusation of inexperience seriously.

5 Likes

Massive changes to the state of the vote as a result of Brantly casting his vote:

Steward’s View - Fireeyesdao.eth

The FireEyes core team and I have spent significant time reviewing all proposals (pre-selection) as well as all final proposals.

Although setting up an endaoment for the ENS DAO is a novel and important step in the progression of the community & treasury, the process and amounts being discussed currently feels like an overstep.

To put our opinion up front, we will be voting ‘none of the above’ and believe the ENS DAO should start with a smaller, more purposeful allocation towards an endaoment.

This RFP sparked great discussion along with A+ proposals from submitters; however, no major DAO has adopted this strategy, and being the first to do so with a majority (80%) of the treasury feels very risky considering the max upside of 1-5% apy outlined by the proposals.

Instead, we want to propose conducting an initial stage, using a smaller amount of the treasury as a test case (~5-20%).

This allows for the community and the operators to implement the Endaoment in practice and iron out any issues without risking 80%+ of the treasury. If successful, the community can vote to allocate more funds in the future.

Another point worth noting is the voting policy of the rank choice voting, although Nick wrote a full explainer here, this type of brand new vote policy is naturally more complex than previous votes and the 1st, 2nd, 3rd rank elimination isn’t easy to understand (thus the graphics and post being needed). Introducing a different style vote system on such an important vote is another final reason why we will be voting ‘none of the above’

Overall the time and energy from the entire ENS community that has gone on here is an incredible testament to the decentralisation and success of the ENS DAO, however in our opinion conducting a more purposeful first step makes more sense.

3 Likes

Can you expand on your reasoning behind the ranking of the other candidates after None of the Above?

The original RFP did not provide for a vote on finalists; the stewards decided to offer the DAO a choice because there were multiple good candidates.

I think your own vote is a perfect illustration of the value of ranked-choice voting: Your own choice of None of the Above seems unlikely to win at the moment. If we were using single-choice voting, you would have to choose between voting your conviction and voting strategically by picking the manager you think will be least bad.

With RCV, you can vote your conviction first, and rank the remaining candidates in the order you believe would be least-bad for the DAO.

1 Like

An update subsequent to Fireeyes’ vote:

Has anybody suggested to invest in IRL land / realestate ??

We could probably afford to buy several developing cou tires with the current treasury pool…

:thinking::desert_island:

Hey guys, Im Artsychoke, one of the 4 Treasury Council subDAO members of the SynthetixDAO. I have been following this debate closely, and have reviewed the offering of each of the participants. Nice to see such debate.

Personally, the issue that I had with Enzyme was that all vaults took too long to be deployed and audited and in the '21 yield opportunity times, it was easier to write your own safe module to automate or permission Treasury tasks.

On the overall discussion, I tend to agree with Karpatkey, and would vote for him as an ENS holder. Dealing with DeFi Treasuries via vote has proven to be clumsy and inefficient by multiple DAOs. The risks out there are dynamic and needs change all the time.

An exampled lived by the Synthetix Treasury Council with the credit crunch that Maple Finance suffered (no funds were lost, fortunately). Lenders there would have to trigger a cool-down period to open a 48 hr window of withdrawal where users would compete for withdrawals whenever borrowers paid. Trying to execute transactions on a multisig was impossible as bots would always execute before. This was a unique situation and had to be addressed writing a custom safe module whitelisting a withdraw function and a keeper to trigger the tx upon deposits. A DAO vote would have not cut it, and tool providers would have not have one ready.

Things I believe Karpatkey does better than competitors, and makes them stand out in this ever changing enviroment is that they manage to:

  1. Maintain non-custodial setup
  2. Not sacrifice as much flexibility for Dynamic
  3. Minimizes governance dependence
  4. A technical team that can write Safe modules
  5. Proven track record

Inside the Treasury Council, we handle things in a similar manner, with all members focusing on different areas (risk, dev, budgeting, etc) and trying to maintain flexibility while remaining non custodial.

I’d recommend Karpatkey for ENS voters.

4 Likes

Another major shakeup as @superphiz’s vote pushes Avantgarde into the lead:

1 Like

My main concern is lending DAO funds to the same type of organisations that created the current market meltdown. It’s a matter of principles: we’re leading an on-chain movement, and we reject off-chain black boxes.
The “real world economy” is not crypto hedge funds.

We evaluated this feature when considering using Enzyme for our solution and discarded it immediately. This is the typical tool looking for a problem.
If you operate as a whale, you quickly realise that slippage is a variable defined by a liquidity you cannot control. In an emergency event, not being able to act due to a self-imposed restriction can be very costly.

@Griff has weighed in, swinging the needle back to Karpatkey… for now.

Terra was on-chain. Its not just a matter of on-chain or off-chain. Thats too simplistic an analysis. The guys who are causing the melt-down now are the guys who didn’t underwrite the risk properly. One of the biggest contributors to this cascade was Terra which was all on chain. If you look at Maple, they clearly underwrote their risks intelligently and with discipline (they recalled most loans before things fell apart).

Goldfinch meanwhile, doesn’t lend to any hedge funds. It’s an amazing example of a protocol accelerates the idea of financial inclusion in emerging markets with an excellent track record and some really good local partners. We think this is a great example of what blockchain can do to empower people.

If you operate as a whale, you quickly realise that slippage is a variable defined by a liquidity you cannot control. In an emergency event, not being able to act due to a self-imposed restriction can be very costly.

The policy is easily over-ridable by the Safe signers (ENS stewards). It’s also optional at the vault configuration stage. That post was not intended to be forced on you but to show-case a simple example which illustrates the architectural differences.

2 Likes

To contribute to the part on helping to assess the technical difference between both Zodiac Roles Module and Enzyme, I have been asked to share the auditors point of view. Full disclosure: ChainSecurity is also a technical council member on the Enzyme Board to support them in keeping the system secure, but we don’t take part in any business or non-technical decision making.

The core feature which in our current understanding is hard to replicate without the help of custom smart contracts when using the Zodiac Roles Module is that Enzyme allows to limit fund managers powers by factoring in third party data sources like Chainlink oracles. This can be used to prevent fund managers from using e.g. Uniswap to execute bad trades in which they profit (e.g. through using a custom swap path which results in very large slippage).

A simplified view of this is that the Roles Module allows to use a system as-is, while Enzyme wraps a system to further limit the possible interactions in a dynamic way. To some degree, you get all the features a third-party system offers in both cases, but if you want other config options not foreseen by the third-party system, Enzyme can either support this out of the box, or has a lot of experience in developing those wrappers.

Responding here in a personal capacity to the last comment:

Historically, significant power in the hands of very few people is very costly, too. Smart contracts, while not perfect, can reduce this need for trust, and while no system is perfect, I personally hope we can get towards one which is better than the systems we had in place before.

4 Likes

When it comes to AMMs, “low liquidity conditions” can be created at will. As evidenced by the ubiquity of “sandwich attacks”; liquidity manipulation is cheap, common, and easy. Is a fund really non-custodial just because the method you can use to drain its assets is named “swap” instead of “withdraw”?

You’re muddying the waters around the risk of making small allocations to Maple and Goldfinch, yet are asking for unilateral powers “in case of emergency”. Ironic, no?

2 Likes

Want to make sure this point doesn’t get lost in the discussion.

Yes, the Zodiac Roles Modifier has been audited in isolation, but it hasn’t been audited within the specific context of non-custodial fund management. Again, Karpatkey largely derives its flexibility from choosing to implement controls by configuration, instead of custom adapters. These configurations should be audited. I am NOT doubting the safety of Zodiac in isolation. I have high confidence in the Zodiac team, its auditors and large bug bounty. What I am questioning—is whether using the Zodiac Roles Modifier alone provides as strong security guarantees as Karpatkey is suggesting. The safest car in the world can still crash if you’re able to drive it recklessly.

3 Likes

Hi nicmm,

I’m Defi Foodie from Karpatkey, thanks for all your thought provoking comments.

Could you please provide an example of deliberate low liquidity condition creation? I don’t think you’re referring to collusion between whales, are you?

I’d argue market manipulation is not easy (it’d be much more frequent if it were), but I think I see your point: “Greater restrictions reduce the chances of malicious actions from fund managers”.

I agree that trust minimisation is crucial in web3, and even more so when it comes to fund management, but there needs to be some level of trust in the fund managers to ensure there’s a healthy balance between the possibilities they have and the prevention of malicious action on their behalf -which would result in their immediate destitution and permanent loss of credibility-.

Our goal as fund managers is to help ensure that ENS DAO thrives in the long term, using all the knowledge we have acquired, the lessons we’ve learnt over these 2 years and the technology we have at hand. We could argue endlessly about the caveats, pros and cons of any technological solution, but we’d like to focus on the fact that at the end of the day, a combination of adequate financial planning and strategy combined with adequate technology to allow the fund managers to work with limited freedom will be what determines if the endowment fund is successful or not.

In case of emergency (and in any other case), we would never ask for unilateral powers, we’d have clear pre-approved restrictions that would allow us to act fast, as we have done several times with the assets we’ve been entrusted with. The result has been that we could always derisk positions in a timely manner, preserving the assets of the DAOs we work with.

Regarding the allocation choices, we are just trying to explain our own conclusions from having carefully reviewed countless protocols. We have come across Maple and Goldfinch before, and we are surprised they represent more than just a small portion of the proposed investment strategies for Avantgarde (we have 0 allocation to black box protocols). A hypothetical allocation of the USDC bucket that could start at 30% to ramp up to as much as 40% further down the line is, in our view, irresponsibly aggressive and not at all small - especially anything in Goldfinch’s Junior Pool. Our partners, Steakhouse, would concur. Some of their members have contributed significantly to developing MakerDAO’s extensive real-world asset investments, both off-chain and hybrid on-chain vaults such as Centrifuge, and have spent considerable resources diligencing the space.

Maple and Goldfinch are great innovations and may be suitable for some risk profiles but, in our view, are not suitable for the Endaoment’s objectives. Regardless of their advantages, these protocols are ultimately off-chain black boxes that would need serious legal due diligence before any investment. With their risk profile, we do not believe they are even suitable for an endowment in any allocation, let alone as much as 40%. Furthermore, even staying on-chain, we would not suggest any allocations to untested protocols such as Interest Protocol, which currently has $193,246 in TVL, but represents 10% of some of Avantgarde’s hypothetical USDC portfolios.

There may well be merits to this strategy. We are just explaining that in our risk management framework, we would never suggest the endowment pursue allocations to protocols like these, let alone in this size. You are, of course, free to conclude differently.

The preset configuration setup has a minimal attack surface, namely the Roles mod smart contract. That is to say, there’s no extra smart contract auditing needed.
A preset configuration only consists of a set of smart contract function signatures, target addresses, and input parameter thresholds, which are allowlisted through the Zodiac Roles mod via a transaction batch. Each of these allowlisting transactions is easily readable through any 4-byte decoder, clearly showing the configuration, e.g. a ‘deposit’ signature and its associated target address. These preset-applying transactions themselves are created using Zodiac’s tools and in collaboration with the Gnosis Guild team.
The attack surface is thus minimised since the permissions that the configured preset gives are reduced to a minimum and can be easily verified to be devoid of any attack vectors.

In summary, auditing the preset is as simple as you can get.

Intro

Hey all.

So as has been discussed a lot in Twitter in the last days and in the Space yesterday this is a really difficult vote to participate in.

Everyone has put so much time in these proposals and there has been so much back and forth here in the forums, twitter and in spaces.

Vote ranking

I will list my vote preference here with a short explanation for each.

1. Karpatkey

Both Karpatkey and Avantgarde come really close in my opinion and it was difficult to choose one of the two as first choice.

Ultimately what made the difference was speaking with projects that have used them before and getting a feel for how their work looks like.

I believe that ultimately the tech stack of Karpatkey and the way their proposal describes they plan to use it will be of the highest benefit to the ENS DAO and guarantee that the Endaoment’s goal will be reached.

I also liked the fact that the strategies that will be followed with Karpatkey all seem safe and as risk averse as possible.

Finally gotta admit the statistics and the way that reporting seems to work in the Karpatkey proposal impressed me and think it will be really useful to the DAO.

2. Avantgarde

A very very close second. Had the pleasure of speaking to some people in their team, listened in the space and read the proposal.

I am aware of the enzyme protocol and had been following it even from when it was called Melon. It’s a really interesting approach and as a tech stack also quite powerful.

One of the things that put me off a bit from the proposal is that despite all we saw last year with insitutional crypto offerings collapsing, Avantgarde seems to insist on using them via Maple.

I do realize it’s only a very small part of their allocation and in the worst of worst case it won’t spillover but it’s one of the things that personally still puts me off.

Finally though I appreciate cryptio as part of the proposal I would appreciate tools that are opensource.

Again … I need to say though both proposal are stellar. Choosing one or the other was hard.

3. None of the above

I am choosing none of the above higher than Lama because I don’t believe we would need to have an external manager which passes every single financial action as a vote through the DAO.

Now about what would “None of the above” mean in reality for us I think it’s something we woudl want to avoid.

We would have to re-convene and find someone else, probably from inside the DAO and take small allocations here and there as suggested by @brantlymillegan here: https://twitter.com/BrantlyMillegan/status/1594799476480286726

Though inviting at first, I have to admit I liked the idea, … I can see how this would easily devolve into arguments about how to manage the funds and in the end we would need to end up giving the power to an individual or org. Plus it would take a lot of time.

So I view the “None of the above” as the option to go with a “non-professional” manager, maybe from within the DAO. For example I am the manager of rotki’s treasury … and I think I am doing okay with the small amount of funds we have.

But ENS is huge. It’s a big project and I think it deserves professional financial management. Which is why this option is ranked as 3rd.

4. Llama

Though I appreciate the proposal Llama wrote, I really don’t think financial management can be effective if it has to pass via a DAO vote for every decision.

As many of my peers wrote above when you manage funds at this size you really need to make quick adjustments and take financial positions within a very short time-frame (minutes or hour/s). A DAO vote and execution would take weeks.

I don’t think this is effective and as such ranked Llama as my last choice.

Closing notes

I want to thank everyone who participated in these discussions. You have all been amazing and especially Karpatkey and Avantgarde people have been so open and helpful in their discussions with me.

I learned a lot through this process.

Whatever the end result, I wish to see both teams thrive and in the end for us in ENS to have the most risk-averse but effective ENDAOment program.

6 Likes