# Flash protocol

## Overview
The Flash protocol is an experimental metaprotocol designed to either deploy new tokens or enhance existing blockchain protocols such as BRC-20, Runes, and others with dynamic token generation capabilities.
For this initial implementation, the protocol extends the existing FL$H token (a BRC-20 token), enabling holders to dynamically generate FL$H⚡ tokens.
We recommend inscribing on the same sat and same UTXO for every inscription used to participate in the protocol.
Sending tokens does not require sending any UTXO, but rather the state of the protocol is updated as inscriptions are indexed.

This Protocol is not an investment.
This paper is not financial advice.
This is computer science.

## Token Deployment
To extend a token using the Flash protocol, you must own the original deployment inscription of that token.
Then use this as the parent inscription for the Flash protocol deployment inscription.
Here is an example of how to define the parameters for an extension using the Flash protocol.

{
  "p": "flash",
  "op": "deploy",
  "tick": "FL$H⚡",
  "genesis": "ab2cf070aca3e5f3cb25d4008d9581be1ab5d9f355080c636c0007ce8ebc3c03i0",
  "burnRate": "0.0018047370354399295",
  "burnFunction": "burnAmount = sendAmount*burnRate",
  "sendFunction": "sendAmount -= burnAmount",
  "flashInflux": "(block.time - lastblock.time)*(1 - burnRate)",
  "userWeight": "(userProtoAmount + userProtoFlashAmount)/(protoSupply + protoFlashSupply)",
  "userGradient": "userActiveInEpoch",
  "userYield": "flashInflux*userWeight*userGradient",
  "flashDistribution": "userProtoFlashAmount += userYield",
  "timeKeeper": "selectTimeKeeper(userWeights, userReputations, blockHash)",
  "timeKeeperReward": "(flashInflux - sum(userYields)) + sum(feeAmounts)",
  "deployTime": "1704305705 + (21000000/(1 - burnRate))",
  "notes": "🕛"
}

## Deploy inscription parameter Breakdown
Each parameter in the deploy inscription for FL$H⚡ plays a specific role in the token dynamics within the Flash protocol.

"p": Identifies the protocol name, which is "flash".
"op": Specifies the operation type, here it is "deploy".
"tick": The token ticker symbol for the token.
When using Flash as an extension protocol, tick is not a necessary parameter as the name is derived from the ticker of the parent protocol with "⚡" appended to the end.
If there is no parent protocol, a token can be deployed natively on the Flash protocol by selecting a token name.
Names can be repeated, but the inscription ID serves as the unique identifier of the token.
"genesis":  When using Flash as an extension protocol, the parent inscription acts as the genesis token being extended.
This parameter is not necessary, as the parent inscription already contains this information, but the inscription or TXID can be added for reference.
"max": If a token is being deployed natively on the Flash protocol, we must set the max supply of tokens to be minted.
"lim": If a token is being deployed natively on the Flash protocol, we must also set the max limit per mint.
"hash": If deployed natively, you may inscribe a hash of the deploy inscription to reserve the tick, and then inscribe the deploy inscription with the parameter "hash" as the inscription ID of the hash inscription within 6 blocks.
"selfMint": If deployed natively, this specifies the number of tokens out of the total supply that will be minted to the deployer.
This value must be less than or equal to the max supply, and if left blank will default to 0.
"burnRate": Defines the rate at which tokens are burnt.
FL$H⚡ incorporates a percentage-based burn perfect for microtransactions, ideal for scalability and future sidechain integration.
"burnFunction": Defines the function that dictates how tokens are burnt.
In FL$H⚡, this happens only when tokens are transferred.
"sendFunction": Defines the function for sending tokens.
In FL$H⚡, tokens are burnt upon being sent.
"flashInflux" or “mintRate": Determines the amount of Flash tokens created each block.
With FL$H⚡ we use the elapsed time adjusted for the burn rate such that approximately every 8 months, 21 million FL$H⚡ is generated.
"userWeight": Calculates the percentage of newly generated tokens each user receives.
"userGradient": Factors user engagement into the yield calculation.
By default, it is 1 if the user was active in the last epoch (protoSupply/(1 - burnRate) seconds), otherwise 0.
"userYield": Represents the product of the Flash tokens created in the current block, the user's weight, and their gradient.
"flashDistribution" or "mintFunction": Increments each user's Flash token balance by their respective yield for the current block.
"timeKeeper": Once the Flashchain (Bitcoin sidechain) is fully implemented, Timekeepers will be randomly selected validators based on their token holdings, reputation, and the block hash by default.
They will inscribe onto the mainchain (Bitcoin blockchain) the Merkle root of the latest block from the Flashchain as proof of off-chain activity.
Users transacting on the Bitcoin blockchain settle fees in BTC, while those on the Flashchain settle fees in Flash tokens.
"timeKeeperReward": Compensates Timekeepers with the formula (flashInflux - sum(userYields)) + sum(feeAmounts).
"deployTime": Sets the start time for token generation in Unix time.
To set the deploy time to a certain block, the keyword "block" can be placed before the argument.
"notes": An optional field for developers to add relevant annotations or comments.

## Timekeepers
Timekeepers will function as validators on the Flash network who ensure the integrity and continuity of on-chain and off-chain transactions.
Every block, Timekeepers update the mainchain with the latest state from the Flashchain by inscribing the Merkle root of the latest Flashchain block.
Users will be able to transfer coins to and from the Flashchain.
When holding coins on the mainchain, transactions require an inscription and incur fees settled in BTC.
In the future, transactions on the Flashchain will be settled in the corresponding token of the metaprotocol (FL$H⚡ in this example).
With the FL$H⚡ token, the Timekeeper reward consists of transaction fees in addition to all the tokens generated from accounts not active in the last 21000000/(1 - 0.0018047370354399295) seconds.
For the tokens stored directly on the mainchain, the Timekeeper reward goes to the wallet address of the miner that solved the block in question.
For the tokens stored on the Flashchain, the Timekeeper that inscribes the correct Merkle root of the latest block on the Flashchain onto the Bitcoin blockchain gets the Timekeeper reward.
If an elected Timekeeper fails to inscribe the Merkle root, the reward and fees accumulate and will be awarded to the first elected Timekeeper to inscribe a correct Merkle root.
If an elected Timekeeper inscribes an incorrect Merkle root, it won't be indexed by the Flash protocol, and the Timekeeper reward will still be up for grabs.

## Mint tokens
When the Flash protocol is used to extend a parent protocol, coins must be acquired or minted from the parent protocol.
For tokens deployed natively on the Flash protocol however, this mint operation allows users to mint tokens. 
Once the deploy time has been reached, additional tokens will be generated according to the parameters specified in the deploy inscription.

{
  "p": "flash",
  "op": "mint",
  "tick": "native_flash_token_incsription_id",
  "amt": "1000"
}

## Transfer Tokens
This operation allows for sending tokens to multiple recipients in one transaction, with an optional transaction fee applying to the entire transaction.
If inscribed on the mainchain, you simply cover the inscription fee, and no fee parameter is necessary.
If on the Flashchain however, a fee can be offered to the Timekeeper.
The "tick" parameter refers to the Flash token deploy inscription id.
For, FL$H⚡ that inscription ID is "517cf105e7f8b4221efddca2ca12e24ca4d097cd292f0ddc69f09cd837886c80i".

{
  "p": "flash",
  "op": "transfer",
  "tick": "517cf105e7f8b4221efddca2ca12e24ca4d097cd292f0ddc69f09cd837886c80i0",
  "fee": "0.01",
  "amts": [
    {
      "amt": "100",
      "address": "taproot_address1"
    },
    {
      "amt": "150",
      "address": "taproot_address2"
    }
  ]
}

## Create listing
Enables users to list their tokens to be traded, specifying the amount of tokens put up for trade, and amount of tokens being traded for.
The parameters "tick1" and "tick2" refer to the token being listed for trade and the token being traded for respectively.
The parameters "amt1" and "amt2" refer to the amount of the token being listed for trade and the amount of the token being traded for respectively.
If the parameter "tick2" is omitted, then by default it will be set to BTC.
An optional parameter "expires" sets the number of seconds the listing is active for.
If no value is set, the listing will never expire unless canceled manually.
To set the expiry time to a certain block, the keyword "block" can be placed before the argument.

{
  "p": "flash",
  "op": "list",
  "tick1": "517cf105e7f8b4221efddca2ca12e24ca4d097cd292f0ddc69f09cd837886c80i0",
  "tick2": "flash_token_deploy_inscription_id2",
  "amt1": "10",
  "amt2": "100",
  "expires": "21000000/(1 - 0.0018047370354399295)"
}

## Cancel listing
Allows users to cancel a previously made listing.
This operation references the specific inscription ID of the listing that needs to be canceled.
The inscription ID points to either the Bitcoin blockchain or the Flashchain.

{
  "p": "flash",
  "op": "cancel-list",
  "inscription_id": "listing_inscription_id"
}

## Trade Listing
Permits users to trade tokens, specifying the inscription ID of the listing they wish to trade for.
The inscription ID points to either the mainchain or in the future, the Flashchain.
If the listing inscription is listed in BTC, the user must broadcast a transaction where the first output is the transfer inscription with the appropriate listing inscription ID specified, and the second output being a transaction for the exact amount in BTC sent to the lister’s taproot address.
If the listing inscription is listed in FL$H⚡ or any other Flash token, the transfer inscription must have the appropriate listing inscription ID specified, and the sender must have the amount of FL$H⚡ or Flash token required.
This inscription will either be valid, and the Flash token balance will be deducted from the sender’s balance, or the inscription will be invalid, and it will not be indexed.
The fee parameter will be only applicable for trades on the Flashchain, as fees on the mainchain will be settled in BTC.

{
  "p": "flash",
  "op": "transfer",
  "tick": "517cf105e7f8b4221efddca2ca12e24ca4d097cd292f0ddc69f09cd837886c80i0",
  "inscription_id": "listing_inscription_id",
  "fee": "0.01",
  "items": [
    {
      "amt": "listing_amount",
      "address": "lister_address"
    },
  ]
}

## Ordinal Contracts
The Flash protocol will support ordinal contracts, Turing-complete scripts that will automate token movement within the network.
They can be inscribed and used as values for deploy inscription parameters.

## Future Timeline
Even after the final Bitcoin is mined in around the year 2140, miners will continue to be rewarded for their roles as Timekeepers. As Bitcoin becomes more of a store of value, the amount in circulation will steadily decrease, leaving miners with diminishing BTC rewards. Well before that time, perhaps Flash tokens can be used to fill this void.
-- Ordinal Engineer