Recruit Smart Contract dev team to develop Automated Strategy

As discussed in Discord chat, the overall goal/motivation is to get an automated NFTX strategy.

a) deposit eth in vault
b) vault used to buy vote weighted allocations of collecdtions at semirandom/scheduled intervals
c) vault closes positions and sells back to market after some period of time (or maybe then puts these through to market)

Auto balancing between more than 2 assets has been seen in tricrypto2 implemented in Vyper.

For a Yearn vault, seems like the dev will follow below link (guide) to implement a vault strategy in Vyper.

Propose hiring 2-3 devs on 40hr workweek to complete the task in 3w-1mo. At a simplified rate of 1ETH per week per dev, estimating 6-10 ETH for the project development.

Source of information:
Getting Started writing a Yearn Vault
Tricrypto code.


there are some other aspects to be considered…

this description focuses on buying assets to avoid front running the ‘winning’ collection (and winning semantics may change over tie)

Another idea is to buy NFTX-based assets corresponding to new Bonds as soon as they are announced. One caveat could be to condition this on marketcapt/treasury ratio < X (where X is sub 1.2)

I think another key aspect would be constructive profit generation. That is, the profitable strategies from this vault should commit to paying out at least some portion of gOHM which is held for a longer period of time. Example: vault makes 10% profit in recent time period, convert 5% into FLOOR and stake it for X months… this params all need to be tuned, but the idea to keep some profits longer term make sense. Another approach would be to mandate some input capital matching from the protocol treasury, which of course would use profits from the strategy to benefit floordao itself

1 Like

More thoughts baesd on feedback from @aeto

Concete focus-

I view two goals:
a) minimize cost of front running and
b) eliminating discretionary sweeping/bonding

Why a) doesn’t matter much (beside being HARD!)

I think we should focus on b) rather than a) and here is why…team already said they do NOT have to bond/sweep collection immediately, I think that’s wise and they should set those expectations by giving it X days minimum before newly voted elections get liquidity of any meaningful size (or the market will adjust eventually).

High Level idea for b)

If the above thoughts are true, that minimizes the need to prevent election frontrunning, which will be HARD anyway. Then instead you can focus on easier problem of building a non deterministic engine to bond/sweep collections in order to meet previously established policy-goals (e.g. $/%/etc. of LP stake or NFTX inventory stake, whatever…!)

Example of b)

Eg let’s say there are two collections approved for sweeping, first determine how far assets are off from target acquisition levels then use that to probabilisticslly weight which one to pick, second step use another function to decide BOND or SWEEP, and in the bond case there can be a proactive sweep to avoid front running.

Next steps

If we come to consensus that building the non-deterministic asset acquisition engine is important, we can mockup a specific set of features to ship for v1.