# Auction Modeling Capacity

https://www.notion.so/0a4f04ee685a40999e4ad751fb5d9946?v=c766a1e82255454aaaec63959af72384&p=821332a68f5744939802f01ccb23cbe6&pm=s

## System components
Need to determine/estimate their load/hardware usage at head of chain after historical ingest
1. Geth statediffing at head
2. Watchers
~~3. Beacon chain ingest~~
~~4. Filecoin parition migration~~
~~5. Tendermint validation and cosmos state machine execution~~

## Assumptions
Need to settle on some assumptions
1. Hardware for each member
2. ?
3. Member behavior (are they expected to add additional hardware or no? technically couldn't they degrade their own hardware/performance to purposely trigger an auction?)
4. If members need(ed) beefier hardware to backfill, they will hold onto that afterwards. If this is true, steady state head-tracking is necessarily going to use only some fraction of the hardware capacity they have/had available.

## Problems
I think to answer these questions with a meaningful degree of certainty it would be helpful (or perhaps necessary in the case of 1 and 2) to:

1. Finish the historical backfill of the FIN. Once this is done we can get a measure of how expensive maintaining and head tracking on a populated FIN and get a meaningful profile of the uniswap watcher (or any watcher).
~~2. Finish beacon chain support so that we have a better sense of its impact on head tracking resources. This will add significant load to the system.~~
~~3. Have a better sense of the Filecoin migration of unused historical partitions. This is still in the early spec stages but will have an associated compute/network/RAM cost to the benefit of disk usage.~~
~~4. Perform some basic laconicd testnet benchmarks. We can probably use other chain’s activity to get good estimates for the base state machine+validation requirements/expense, but I also suspect our network activity will be rather unique in its profile (e.g. no IBC activity; no delegation activity; no contract deployment or arbitrary app usage activity). I think this can probably be resolved through some thought exercises and extrapolation from other chain’s activity, but I certainly haven’t walked through that yet.~~

## Action plan/TODO
Figure out what quicknode's margins are
Find alchemy deck

Convey that this isn't a technical question; it cannot be answered by technical evaluation (at this time).

Talk to figment/litmuscap (e.g. they have graph pitch deck and have answered similar business dev/analysis questions)

## Notes
Members can ultimately decide when auctions trigger (they decide how much hardware to buy)

Sources of income:
Validation (negligible)
Service providing (supposed to be the main source)
Auction payout (members are fixated on this)
Equity
Token

Input costs (machines) needs to be ~10-20%