GIP-26: Open market FIDU purchases with USDC reserves

Proposals
1

Authors : nanojohn

Summary : Goldfinch should use a portion of its USDC reserves to purchase FIDU tokens on Curve while they are trading at a discount to NAV. This will have the dual purpose of signaling strength in the protocol to other participants while also capturing a unique opportunity to grow reserves for future projects & needs.

Motivation: We are in an unprecedented situation where high utilization of the Senior Pool funds has led to FIDU tokens trading at ~15% discount to NAV on Curve. Meanwhile, the Goldfinch USDC reserves are sitting idle and not being utilized to generate additional yield at this time.

Specification & Requirements:

  1. A fixed amount of protocol USDC reserves (for example, 500,000 tokens) will be allocated for buying FIDU tokens on Curve if purchase conditions are met.
  2. A minimum percentage discount to NAV will be predetermined as a purchase condition, so that buybacks only occur when the Curve price < (1 - discount) * SharePrice, where SharePrice = NAV and discount = % threshold such as 5%.
  3. Break up the purchases into small, regular transactions to occur. For example, we may agree to exchange 500,000 USDC for FIDU in 1 transaction or 50,000 USDC for FIDU on a weekly basis.

This proposal requires the creation of the following protocol parameters:

  • USDC amount to allocate to purchases of FIDU: The $ or % amount of protocol reserves to earmark for FIDU purchases. We are initially proposing $500,000 USDC.
  • Discount to NAV threshold: The % discount to NAV that FIDU must be trading for an open market purchase to occur. We are suggesting 5%, so a regular transaction would occur if USDC/FIDU rate on Curve < (1 - 0.05) * SharePrice.
  • Frequency of and sub-divided amount per transaction: How often and how many tokens should we exchange in each transaction? We think a single 500,000 USDC to FIDU would minimize the operational burden if entry price < (1 - 0.05) * SharePrice. Otherwise, we can make 1 purchase up to this price and save the balance for a future purchase if price reverts lower.

Benefits:

This proposal would operate as a short-term measure to help the liquidity situation while GIP-25 is approved and implemented.

  1. This would allow the protocol to earn revenue on its USDC reserves in the form of Senior Pool interest payments and trading profit. A $500,000 USDC investment in FIDU would generate ~$90,000 of profit for the treasury if held for 1 year ($48,000 of trade profit from buying FIDU at discount and $42,000 of interest payment profit), which is an 18% APY and a very competitive return. This assumes reserves do NOT stake for GFI rewards, which could add even more.
  2. These purchases would signal goodwill and strength to the general public by showing that Goldfinch has skin-in-the-game.
  3. If the spread vs NAV begins to shrink in the secondary market, MEV bots will be less incentivized to extract value from senior pool, opening up opportunities for users to withdraw.

Drawbacks and Risks:

  1. These funds are at the same risk as any other LP in the fund, with the potential of borrowers to default and not return capital or for utilization to be high, making funds unavailable for withdrawal.

Voting :

Yes: Allocate a specific amount of protocol USDC reserves for regular open market Curve buys of FIDU if purchase conditions are met.

No: No allocation of reserves

1 Like
2

Agree. But we need to think about frequency and an amount. I do not think that 50k USDC a week is a good way to go. I think it should be a percentage of the pool.

3

Agree. But we need to think about frequency and an amount. I do not think that 50k USDC a week is a good way to go. I think it should be a percentage of the pool.

I think this is a good idea. If we limited to ~0.50% of the pool, we would allow transactions up to ~27,500 USDC. Alternatively, we could set a maximum “Price impact”, such that we limit the size of the transaction so that Price Impact < 0.10% for example.

4

Hi, this is Mike, cofounder at Warbler Labs.

I think this is a very interesting proposal, @nanojohn, thank you for writing this! Our internal view at Warbler is that this would be fairly low-risk for the protocol on the downside, and also unlikely to be a “gamechanger” for the protocol on the upside, so we’re pretty neutral and curious to see what the community chooses.

If possible @nanojohn, I would propose one operational adjustment, which is to reduce the number of transactions required. Doing regular purchases would be a lot of work for the Governance Council, and I don’t think the incremental discount would be worth that operational hassle. A single $500K purchase on Curve today would cost $1.030 per FIDU, which is still a 5.3% discount to the current $1.0945 Senior Pool sharePrice.

My proposed adjustment to the implementation is: do a single purchase on Curve of up to $500K until the price on Curve reaches the NAV FIDU share price. And then for any amount of the $500K remaining, do additional $100K+ purchases (or the full remaining amount) when the price falls, up to the NAV FIDU share price.

The tradeoff of this adjusted implementation is that the community may not get quite as good of a discount on the whole $500K purchase amount, but the benefit is this will be much easier to actually execute, which means the community will see the benefit much faster and it will not require significant ongoing monitoring or activity.

1 Like
5

I support this. FIDU is available at a great discount. It’s good for the protocol. I would prefer for to go with less frequent (maybe quarterly) but bigger ticket size transactions. FIDU should be bought from USDC reserves as long as the discount is >5%.

6

Yes! I support this proposal as it helps the current liquidity condition as well as it increases the Goldfinch reserves by earning additional yield.

7

I agree that this could be a nice way to earn some extra yield and temporarily reduce the discount on Curve.

What is going to stop the discount from returning on secondary markets after the capital is exhausted? In closed-end funds for example, the fund is able to liquidate assets to be able to buy its shares at a discount on the open market. That action is actually accretive.

GIP-25 is a great proposal and a welcome change to the liquidity dynamics, but isn’t the “high utilization” of the Senior Pool due to lack of new capital inflows into the Senior pool that are greater than the capital outflows of the Senior Pool? There is a backlog of loans to be made, but the Senior Pool can’t seem to accumulate capital to be able fill the loan demand.

Are there other ways we could allocate $500,000 to address the actual underlying problem?

8

Thank you for the operational insight. I figured this might be the case. Perhaps a nice middle ground between operational burden and price impact would be to split the transactions into 2x $250,000 purchases.

As you can see from the below screenshots, a 250K transaction has a 1.2% impact vs a 6.0% impact for a 500K transaction. This option of 2 transactions has the potential to save ~$12,000 in price impact costs.

Fidu_250

Fidu_500

9

Nothing is stopping other users from selling FIDU after these purchases, causing the discount to return. The goal of this proposal isn’t necessarily to just try to reduce the spread to NAV, but also to 1.) grow USDC reserves with a unique market opportunity and 2.) signal strength in the protocol to other participants by showing Goldfinch has capital invested alongside other LPs.

Remember that regular borrower interest payments along with any bullet principal repayments are also inflows into the Senior Pool. Thus, even if no new LP capital flows into the protocol, utilization will decrease with time as these borrowers continue to repay the loans.

10

Yes, I think two transactions definitely works. Since the price is always changing, it might be easier to specify it as $250K+ transactions, with at least a [X]% minimum discount to NAV, for a total of $500K. That way we can do the first transaction as much as possible up to the price we’re OK with, and then wait for whenever the price falls again enough to buy the remaining.

11

This is a great proposal! Not only it would reduce the sell pressure on the secondary market, but also show strength and confidence in the senior pool. In addition to one or two lump sum transaction, I think it would be worth considering doing some monthly FIDU buyback as a percentage of the protocol revenue.

1 Like
12

@nanojohn Would you be open to amending the proposal, either what you suggested or what I suggested in my reply, to have it effectively reduce the number of required transactions? I think it would be good to have an amended version before it goes to Snapshot vote.

13

Hi all -

Long time lurker, first time poster. My name is Erin and I work for Avantgarde Finance, we’re the lead maintainers of Enzyme. I’ve been watching Goldfinch for a long time and have spearheaded our efforts to integrate the various parts of the the protocol into Enzyme so they’re accessible for our vault managers. This summer we implemented a FIDU price feed so vaults can buy and sell on Curve (via Paraswap). We have several large deals in our pipeline where Goldfinch will play a large part in our allocation strategy. Scoping work has continued, and I believe we’ll be able to integrate the Junior pools as well as direct access to the Senior pool in the coming months.

I saw this proposal and just wanted to point out that the operational concerns @mikesall raised would be entirely mitigated if it was run through an Enzyme vault. Read on below to learn how three transactions by the Governance Multisig can enable infinite flexibility in entering and exiting the FIDU market on Curve while maintaining the DAO’s absolute custody over its funds…

Enzyme Vaults - Overview and Trust Model
Enzyme is the DeFi operating system. A key component of its architecture are “vaults”. These highly customizable contracts hold tokens and allow for them to be managed actively by connecting directly to the contracts of various DeFi protocols. There are three primary roles in a vault, each of which is represented by an Ethereum address. I’ll describe them below.

Vault Owner
Each Vault is a distinct contract deployed to the Ethereum mainnet. These contracts can be configured at the time of their deployment to have various characteristics. The contract’s configuration and deployment is executed by the Vault Owner, who retains sole control over reconfiguration of the vault’s parameters throughout the life of the Vault .

Depositor
Vaults exist to manage the assets of Depositors. They can be configured to accept any address as a Depositor, or Depositors can be limited to a list of permissioned addresses controlled by the Vault Owner. Depositors send assets to the vault and in return receive a number of share tokens that represents their pro-rata contribution to the vault’s AUM. Generally the share token allows the Depositor to redeem from the Vault at any time.

Asset Manager
Vaults can interact with a large number of decentralised finance protocols to allocate the assets they hold. Asset Managers are addresses that have been delegated permission by the Vault Owner to interact with those protocols on behalf of the Vault. They can either trade on all the protocols with which the Vault has been enabled to interact, or the Vault Owner can specify a subset of those protocols for each Asset Manager. Additionally, the Vault Owner can always remove an Asset Manager address’ permissions instantly and without notice. By default, the Vault Owner is also an Asset Manager that can trade on all of a Vault’s enabled protocols.

In the context of this proposal, I would suggest:

  • Governance Multisig creates an Enzyme vault that can only trade on Paraswap and where the multisig can be the only depositor
  • Governance Multisig deposits USDC into the vault
  • Governance Multisig delegates permission to someone to trade on behalf of the vault
  • The delegated trader can opportunistically buy FIDU with USDC without needing to aggregate 6 signatures every time they do it, meaning they can execute in smaller chunks and with less price impact

Benefits

  • Low operational overhead for Governance Multisig
  • Better execution / less slippage / more profit $$$
  • Extensible - could easily accommodate future changes e.g. @ValJean 's suggestion to do monthly FIDU purchases with protocol revenue (would require one tx from Governance Multisig)
  • Transparent - The Enzyme app is underpinned by a comprehensive data pipeline, including 7 different subgraphs. Every transaction is logged and displayed in an ongoing activity feed. Additionally, we support a white label product that would allow Goldfinch to have a dedicated URL pointing to its vault (you can see an example of that here). While it’s true that the USDC and FIDU would leave the Multisig, it would be holding Vault Share tokens instead.

Risks, Caveats and Outstanding Questions

  • Who is the delegated trader? I’d suggest either a smaller subset of the governance council (2/5 maybe?) or @nanojohn as the original author of this post. Note that you could also opt to pay the trader a small fee (payable in Vault Shares) so that they’re incentivized to a) keep their job and b) make the best possible trades.
  • Additional smart contract risk is unavoidable in this implementation. However, Enzyme’s been in the wild since 2019 and is rigorously audited by Chain Security and others. There’s a generous bug bounty program with Immunefi. Two major insurance protocols run large portions of their treasuries on Enzyme, which is a particularly meta vote of confidence.
  • Fees: Enzyme charges 25bps of AUM annually, and it might make sense to pay your delegated trader if it’s not a known entity / governance multisig. I’m happy to chat more about fees IRL, or you can read about how the protocol charges and pays them here.

I’m confident in recommending Enzyme for this application, and am happy to field any questions the community may have.

14

Hey! Thanks for putting all this together. However it seems to be another proposal, which should be firstly supported by the community on the server in the #proposal-ideas channel. Here is the full guide: Goldfinch Governance Guide V1 how to go ahead with your proposals in case you want to proceed further.

15

As mentioned on Discord, the implementation of this proposal is currently on hold due to a significant drop in liquidity in the Curve pool. At current prices, we only have the ability to exchange ~$25,000 USDC → FIDU while remaining below the 5% discount level.

A few alternatives to implementation are currently being considered including:
1.) Waiting for liquidity to increase or price to skew such that we can exchange more USDC → FIDU on Curve
2.) Investing the $500K of reserves directly into the Senior Liquidity Pool, but not until GIP-25 is implemented to allow the withdrawals to be equally distributed (rather than go to bot arbs)
3.) Acquiring FIDU and pairing it with USDC from the reserve to provide more secondary market liquidity on Curve pool

16

Council has approved the proposal

17

Yes, I think two transactions definitely works