# Flashbake Grant Proposal 2

Please throw your ideas and let's come up with deliverables.

## Marketing Efforts

### Block Explorer Integration

Work with block explorers to add badges or other flair to validators who have an address registered in the Flashbake smart contract.

Optionally, find a way to let them flag certain blocks as having contained a Flashbake transactions

### Wallet Integrations

Work with wallets to support Flashbake relay out of the box.

Example: https://github.com/madfish-solutions/templewallet-extension/pull/787/files

### Revamp Flashbake.xyz

Add some better docs, make the landing page clearly state what we do

### Start the Flashbake Flywheel with Transactions

Users won't use Flashbake (or will have a poor UX) today because there are too few bakers. Since no one uses Flashbake, bakers don't have incentives to run more software.

We could change this by submitting transactions to the Flashbake network at a loss. Given some money, we could purchase some XTZ and place it in a hot wallet. We could then submit Flashbake txs that move XTZ from ourselves, to ourselves, with higher-than average tx fees. This would incentivize bakers to join, as they would want to capture these fees.

To accomplish this, we could (temporarily) modify our relay to have the following code:

const flashbakeIncentivesWallet = new Wallet("privateKeyForSomeFlashbakeRelay")

if (nextBakerIsFlashbake) { // We have a chance to send a tx to a baker via flashbake
   const txs: Array<Transaction> = getTransactionsInRelay()   

   if (txs.length !== 0) { // There are Txs in the relay
       sendTxToBaker(txs[0])
   } else { // No transactions in relay
       sendTxToBaker(
          from: flashbakeIncentivesWallet.address // Send from our wallet
          to: flashbakeIncentivesWallet.address // ... To ourselves (I think this works) 
          amount: 1 // any amount since we get it back
          fee: 1000000 // Attach 1 whole XTZ as a fee
       ) 
   }
}

This has the effect that there is always a Flashbake transaction with higher than average fees, but that we don't compete with users. Bakers will want to join to get these fees, which in turn means more users will have a better experience. This also has the effect that as more users join the relay, we will spend money more slowly.

There's a few neat variations to this that might make it more interesting as well:
- Send txs at random times
- Set fees as random numbers (ex. 1 XTZ most of the time, but 5 XTZ in 5% of cases)
- Increase the fees paid based on the number of blocks between Flashbakers (ex. fees really on average with one baker; but slowly decrease as more bakers join)

## Metrics

Find a way to mark a block as "Flashbaked". For instance, deploy a smart contract with a single entrypoint ("flashbaked"). Insert a second transaction in every block - a 0 fee call to the contract such that every Flashbake block has:

[
  <winning operation from flashbake>
  <call to metrics contract>
  <... txs from mempool ... >
]

Otherwise:

[
  <... txs from mempool ... >
]

Then with an off chain indexer, we can find the number of flashbaked blocks by:

const METRICS_CONTRACT = "KT1..."

const block = getBlock(someLevel)

const txs = block.txs
const baker = block.baker

const specialTx = txs[2] 
if (
    specialTx.to === METRICS_CONTRACT, // second tx called metrics contract
    specialTx.fee === 0, // with a zero fee
    specialTx.from === baker, // by the baker of the block (prevents people from spoofing this)
) {
    console.log("This block is a flashbake block!")
}

We can be reasonably sure a 0fee tx shouldn't be at the start of the block, and bakers have no incentive to try to spoof this metric. It also costs the flashbaker nothing, besides a trivial amount of blockspace and we can turn this off as a feature when block space is no longer ample, by that time Flashbake is probably already widely used or has failed.

Given this works trustlessly by scraping chain data, we could perhaps convince block explorers to expose this in their UI?

## Tech debt

* relay and endpoint should time out operations (if the hash inside the operation is more than 120 levels old, we discard)
* relay and endpoint should be aware of finality (HEAD-2 is finalied) and not consider operations included until they are in a finalized blocks

1.5 day worth of work for the 2 above

* remove the concept of cycle: all we care about is the list of bakers for the next 120 blocks, so we can query these on a rolling basis (per-cycle right query freezes the node anyway so we are no longer doing this)

4 hours

* manage priority 1 (round 1): if a baker failed to bake, and the round 1 baker is a flashbaker, we shold send it our payload

4 hours

* filter out any operation that's not a transaction: we don't want them in flashbake mempool, forward them to the actual mempool instead

4 hours

## Support multiple transactions

Today, when the endpoint receives 2 transactions in 2 bundles, it will include the winning auction one.

After chatting with Vbot today, it would probably make sense to include both in some scenarios: indeed, the baker will apply the same treatment to flashbake operations than regular operations: check that they are valid and not conflicting etc.

But what happens with the auction then? A solution would be to add some "order type" semantics around the bundle: `FIRST_OR_NOTHING` would be subject to auction to put at the beginning of the bundle or else be dropped. We default to `ANY_POSITION`. The relay by default submits at `ANY_POSITION`, only searchers or bots use `FIRST_OR_NOTHING`.

## Support bundles

This should be easy. In the endpoint, we just need to sum up the fees of every transaction in the bundle and include it.

"Bribes" from the searcher can take the form of dummy transactions from the searcher to itself with a high fee, and an expiry level such as it's only valid at the target level and then expires.

It could also be a transaction from the searcher to the baker with similar expiry level. This is a deterrent against reorg attacks. In this case, we also need to look for transactions to the baker in the bundle.

## Example of searcher script

Provide examples of bots.