This proposal will include pieces of all the proposals above as some combination of these is the best answer.

Things to consider -

  1. ETH pool is currently at 6 ETH and 1,276,568.7899061 (see below chart)
  2. The data I am using is included in the below table

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/f89b087a-7a04-4277-af4a-3bb49ff2b184/Thorchain_-_ETH_Hack_Data.pdf

  1. The LP activity from Height - 1478894 (pre hack) needs to be considered and adjusted to the fix - otherwise it seems to me we are overfunding the problem and double paying LPs that w/drew between the pre hack height and height 1483166. I do not have this data to analyze yet
  2. The pre-hack pool value for prices at the time of the hack and divide by the LP units outstanding is $16.20 and the pre-hack pool value at current price is - $13.55. I have not yet considered who takes this loss due to price movement from hack height (see [TehColeSlaw] comments below) - if LP take this loss the liability to treasury is reduced.

The road map to Asgard - "Divided we are Wrong - Together we are Strong"

  1. NO should contribute back their windfall gains from this hack - this is an investment back into themselves and the platform. They should be rewarded with the historical bonding APYs and not a big bonus based on the hack fees generated.

    1. a side project (for a later date maybe) should be to look into how the fees on this hack were allocated and audit it - I believe [TheArchitect] said he may have a tool to do this.

  2. All arb trades in ETH in the queue should be refunded so as not to have further negative impact on TC.

  3. It still seems to me the ERC 20 pools should have a similar analysis before they are open to trade or withdraw - I have only studied the ETH pool so far. At first glance some of these pools still look out of balance.

  4. The balance sheet should be updated for all other obligations - this one only currently reflects the liability for the fix but should include Accounts Payable, S-T other Obligations, L-T obligations, etc.

  5. Other options to consider -

    1. Use current liquid asset position (all assets on the table except RUNE including LP position) to fund the 4,232.9927301 ETH (less the adjustment for LP withdrawals and potential value loss absorbed by LP in [TehColeSlaw] comment below). How much USDC, BTC, BNB or existing LP positions should be somewhat proportional to not significantly change the asset mix on the balance sheet (unless that is intended).
    2. Do NOT currently sell RUNE into this market at current prices! - OTC or in the market. I think that is a bad signal to the market and should only be considered after all other options have been exhausted. (See item h below is a RUNE buy back option - the complete opposite of this - also not a good idea right now). i.e. I would not be buying or selling RUNE from the treasury currently if I had other tools to solve this shortfall.
    3. Consider establishing a Line of Credit (if available) to provide future liquidity and give flexibility on treasury function in the future - I would consider very carefully before using debt to fix this problem right now. If this LOC was used for a short-term (say 30-60 day) bridge loan to fund the ETH insolvency with an understanding it would be paid off from Treasury at end of month if other capital is not raised at favorable prices is a smart use of the LOC. I like having the tool for future Treasury moves when balance sheet is firmed up. Leverage is very dangerous for this kind of balance sheet in a down or sideways market. I would only use this LOC if there are no other options besides selling RUNE in OTC or in market. Praying for a price recover is not a strategy.
    4. Consider contributing the Treasury LP position to the pool to lower the outstanding LP units and close the shortfall. This is one of the biggest assets on the balance sheet - not sure of unintended consequences I am not considering to do this.
    5. Open up all potential discussions with VC firms to raise capital. As a public company CEO and CFO the biggest mistake you can make is not raise aligned money when it is available - most regret that after the fact. Use the community experts to be involved in this process to build management team in areas VC's would want to see experience. VC participation will make the project stronger.
    6. Make sure financial community is heard before trading is opened and all options are considered. If it was the delay of the 3 nodes upgrading then that technical matter needs to be carefully considered before the "live button" is turned on. There was no chance for that strategy to work (except for benefit of the Arbs and those pulling funds off the system - certainly not TC at that point) once the exchange was trading and the fix was not fully implemented due to the delay in getting 100% update. It quickly became a run on the bank.
    7. Scrub the code for any other obvious "remarks" that are a road map to a hack (see REKT.news analysis if correct)
    8. Not sure now is the best time to implement and execute a proper RUNE buy-back program with our precious treasury funds. The price will recover if we get the right fix and time proves we are stable. Generally these do not work.
    9. I know this has been mentioned but to be complete - do not open the ETH chain until all reviews and audits have been completed - then maybe consider L1 ETH first and then bring back ERC20 when tested and audited.
    10. Ask community to return extra Arb and LP withdrawal windfalls as show of support for the project and long term success (like ALCX did) - consider a NFT to those that participate - maybe even offer a bounty so keep 10% and return balance to show support.
    11. The Dev community should consider kicking in RUNE to the treasury to participate with the LPs, the NO and to provide a strong incentive for the community to give back as described in j above.
    12. Include a Chief Financial Officer (type) in the core team - they can coordinate all these matters, watch the balance sheets (that includes TC and all the pools are basically separate balance sheets), treasury function, insurance requirements, VC raise, LOC or Debt raise (i.e. capitalization), community and public relations on financial matters, analyze financial attack vectors, financial modeling, etc. They can also begin to consider, propose and implement plans to decentralize the treasury function safely amongst the community for when the time comes. This person should also create policy and procedures around the CFO/Treasury function so there are guiding principles that can be used and referred to in order to best navigate the growth. Once you have this prioritized it provides a framework and process to make these big decisions.
    13. Get a commitment from core team to expand their Planned Obsolescence (current schedule for 2022) to a later date, perhaps tied to X number of months after Mainnet launch with no exploit. This will signal to the investing community that the team is here to stay and will not step-away until the protocol is hardened.
    14. As discussed in MCCN, when the resources are available - implement NO communication tool so that they have practical ability (without being slashed to death) to provide a true vote up or down on each update and thus strengthen the security protocol. There is clearly huge brain power and knowledge in the NO and community - lets use the technology to accumulate all that brain power into "best practices" for TC
    15. There is NO need to consider raising the 500,000,000 RUNE cap - that would have a negative effect and is effectively a stock split. This would make this fix harder to solve - stock splits are not economic fixes and do not work!
    16. Maybe re-consider the "chaosnet" moniker as words are very powerful - I understand it as a kind of "warning" or "disclosure" but it really isn't and maybe TC has outgrown it.
    17. Pay a reasonable bug bounty to the hero that reported this hack - we all owe this person a huge amount of love and gratitude - thank you @emilyrutherford!

    Timeline and Key Milestones

    1. Immediate (i.e. ASAP)
      1. Decide what LP value you want to reset the ETH pool at - either $16.32 or even $16.20 (will give withdrawing LPs windfall over others who stayed) or at $12.00 to $12.50 as proposed above. [From TehColeSlaw] The math calculates that $13.24 is the correct price to target for a complete make whole (based on current ETH, RUNE prices). My $12.00-$12.50 proposal was to illustrate that other LP prices can be targeted. There may be adverse PR as a consequence of less than 100% fix.
      2. Decide if you will adjust pool value for reduction in LP units from 1,009,519.87535883 to 990,697.19755601 - these are the effect of the LP w/draw that went out post hack.
      3. Decide how to fund the shortfall (as decided in a & b above) - which assets our of treasury, sale (OTC or Market not preferred), borrowing (can this be done timely to get exchange running) and or VC (this is generally not a 48 hour process but maybe in Crypto it is now)
      4. Ask for participation from community (NOs, Arbs and Devs) to support funding the liability [From TehColeSlaw] Consider asking ecosystem projects which plan future airdrops to show particular generosity to the wallets that participate in any community funding efforts
      5. Refund all pending arb trades
      6. Reset the pool
      7. Push update fixes and kick start the network begin to rebuild momentum (minus ETH or ERC20?)
    2. Mid - Long term -
      1. Implement items 4 and 5f, 5l, 5m, 5n, 5p, and 5q

    [TehColeSlaw] The above table frames the problem and solution very well! This fix, as I read the table, targets an LP value of $16.32. But markets have dropped and the LP value would be much lower as a consequence. I would add to this proposal an adjustment for the price action.

    If the starting LP value was $16.20, ETH price dropped from $1,890 to $1,815 and RUNE dropped from $5.41 to $3.65, we could use a different LP target price for the fix balances to be contributed. The calculation is as if an LPer held an equal amount of ETH and RUNE during the period of the attack.

    [Petdetective006] Yes - I agree with this analysis - See my things to consider comment 4 above - you are making a good point and I am not sure who takes that loss - we need to think about it. Don't forget to adjust for LPs that w/drew post hack

    Pros

    Cons

    [how does this shift burden to LP? It actually allocates the burden to all and protects the LPs that were unable to withdraw fully - they are made complete? Please explain how you see it?]