ltc-20

Read every word if you decide to test. These will be worthless. Use at your own risk. (forked from @domodata twitter) https://domo-2.gitbook.io/brc-20-experiment/

This is just a fun experimental standard demonstrating that you can create off-chain balance states with inscriptions. It by no means should be considered THE standard for fungibility on litecoin with ordinals, as I believe there are almost certainly better design choices and optimization improvements to be made. Consequently, this is an extremely dynamic experiment, and I strongly discourage any financial decisions to be made on the basis of it's design. I do, however, encourage the litecoin community to tinker with standard designs and optimizations until a general consensus on best practices is met (or to decide that this is a bad idea altogether!).

What are BRC-20 tokens on Bitcoin? | Myth.btcMyth.btc

Must read summary of the experiment thus far. by https://twitter.com/mythbtc

Idea

Experiment to see if ordinal theory can facilitate fungibility on litecoin

• Create a ltc-20 with the deploy function

• Mint an amount of ltc-20's with the mint function

• Transfer an amount of ltc-20's with the transfer function.

ltc-20 balance state can be found by aggregating all of these function's activity together.

• Deployments initialize the ltc-20. Do not affect state

• Mints provide a balance to owner of the mint function inscription until a TRANSFER f(x) is called inscribed. (view chart below)

• (Transfer f(x) is the only want to send now, watch out for scammers)

• Transfers deduct from the senders balance and add to the receivers balance, only upon the first transfer of the transfer function. (1. Inscribe transfer function to senders address 2. sender transfer's transfer function)

Front end

Dune dashboard was meant for demo purposes only and is already broken/obsolete. Will keep live to demonstrate the logic required to determine state.

ordinals brc-20 experimentDuneAnalytics

THIS IS A BTC VERSION

In the meantime some marketplaces are inscription services are working on a functioning indexer. I will list solutions as they come online

• (These will all be BTC versions for placeholders for now)

• https://litescribe.io/ltc20 (full balance state and explorer functionality)

• https://litescribe.io/search (no state, search functionality only)

• https://github.com/Next-DAO/brc20_indexer (no state, lite search functionality only)

How to

Getting a balance

You can either deploy your own or mint from existing deployments litecoin punks style

1. (Optional: Only do if you want to create your own ltc-20. If not go to step 2) Inscribe the deploy function to you ordinal compatible wallet with the desired ltc-20 parameters set.

2. Inscribe the mint function to your ordinal compatible wallet. Make sure the ticker matches either a) the ltc-20 you deployed in step 1, or b) any ltc-20 that has yet to reach its fully diluted supply. Also if the ltc-20 has a mint limit, make sure not to surpass this. Careful if using inscription service. Some tools inscribe to themselves first then forward it to the customer (thus the intermediate inscription service owned address keeps the balance)

Transferring a balance

1. Inscribe the transfer function to your ordinal compatible wallet. Make sure the transfer function inscription information is valid before inscribing . Careful if using inscription service. Some tools inscribe to themselves first then forward it to the customer (thus because the intermediate inscription service owned address has no balance and the transfer function is wasted). Some ordinal wallets generate a different address each time, make sure to send to the address that holds the balance.

2. Once received, (and if valid) send the inscription to the desired destination to transfer the balance.

What is valid?

A valid transfer function is required to transfer a balance. Validity can be determined by the following:

• Valid transfer functions are ones where the amount stated in the inscription does not exceed Available balance when inscribed.

• Available balance defined as: [Overall balance] - [valid/active transfer function inscriptions in wallet (Transferable balance)]. If there are no valid/active transfer functions held by an address Available balance and Overall balance are equivalent.

• Example: A wallet holds an Overall balance of 1000 "lite", and . The holder then inscribes a transfer function of 700 "lite". Once the inscription is confirmed, the following is true: Overall balance = 1000, Available balance = 300, Transferable balance = 700. If in the next block, the user tried to inscribe a transfer function of 500 "lite", this would not be valid as the maximum amount that can be inscribed is 300 (Available balance).

• If multiple transfer functions are inscribed in the same block, validity is determined by the order the were confirmed in the block.

Redundancies

• If a user changes their mind and no longer wishes to transfer their transfer function, and wants to restore their Available balance to the Overall balance (invalidate Transferable balance), the user must simply transfer the transfer function inscription to themselves.

Notes

• Do not send inscriptions to non ordinal compatible wallet taproot addresses

• It is unlikely that balances will be safely tradable using existing marketplace infrastructure. Under no circumstances does the transfer of a mint function result in a balance change.

• Each transfer inscription can only be used once

• The first deployment of a ticker is the only one that has claim to the ticker. Tickers are not case sensitive (LITE = lite).

• If two events occur in the same block, prioritization is assigned via order they were confirmed in the block. (first to last).

• Minting transfer inscription to yourself first is necessary to avoid others spending your balance

• For public ltc-20 mints the bitcoin punks / .lits names 'first is first' approach is adopted

• The mint function and the second step of the transfer function are the only events that cause changes in balances

• The first mint to exceed the maximum supply will receive the fraction that is valid. (ex. 21,000,000 maximum supply, 20,999,242 circulating supply, and 1000 mint inscription = 758 balance state applied)

• Mint function inscriptions do not have a padding requirement

• No valid action can occur via the spending of an ordinal via transaction fee. If it occurs during the inscription process then the resulting inscription is ignored. If it occurs during the second phase of the transfer process, the balance is returned to the senders available balance.

• Number of decimals cannot exceed 18 (default)

• Standard limited to uint128

• Maximum supply cannot exceed uint64_max

Operations

As I mentioned above, this is just my fun experimental standard design. I welcome anyone to improve upon the design, rules, or compression issues it poses. For traceability json {} are required, as well as the minimum required information to satisfy one of the functions. (json inside of txt files work)

Deploy ltc-20

lite used for demo purposes in the docs. It has almost reached its max supply.

{ 
  "p": "ltc-20",
  "op": "deploy",
  "tick": "lite",
  "max": "84000000",
  "lim": "4000"
}

//Written Like This Below For Inscribing//

{"p":"ltc-20","op":"deploy","tick":"lite","max":"84000000","lim":"4000"}

Key	Required?	Description
p	Yes	Protocol: Helps other systems identify and process ltc-20 events
op	Yes	Operation: Type of event (Deploy, Mint, Transfer)
tick	Yes	Ticker: 4 letter identifier of the ltc-20
max	Yes	Max supply: set max supply of the ltc-20
lim	No	Mint limit: If letting users mint to themselves, limit per ordinal
dec	No	Decimals: set decimal precision, default to 18

Mint ltc-20

Careful if using inscription service. Some tools inscribe to themselves first then forward it to the customer (thus the intermediate inscription service owned address keeps the balance)

{  
  "p": "ltc-20",
  "op": "mint",
  "tick": "lite",
  "amt": "4000"
}

//Written Like This Below For Inscribing//

{"p":"ltc-20","op":"mint","tick":"lite","amt":"4000"}

Key	Required?	Description
p	Yes	Protocol: Helps other systems identify and process ltc-20 events
op	Yes	Operation: Type of event (Deploy, Mint, Transfer)
tick	Yes	Ticker: 4 letter identifier of the ltc-20
amt	Yes	Amount to mint: States the amount of the ltc-20 to mint. Has to be less than "lim" above if stated

Transfer ltc-20

Careful if using inscription service. Some tools inscribe to themselves first then forward it to the customer (thus because the intermediate inscription service owned address has no balance and the transfer function is wasted). Some ordinal wallets generate a different address each time, make sure to send to the address that holds the balance.

{ 
  "p": "ltc-20",
  "op": "transfer",
  "tick": "lite",
  "amt": "100"
}

//ltc-20 may need some work in this area.//

Key	Required?	Description
p	Yes	Protocol: Helps other systems identify and process ltc-20 events
op	Yes	Operation: Type of event (Deploy, Mint, Transfer)
tick	Yes	Ticker: 4 letter identifier of the ltc-20
amt	Yes	Amount to transfer: States the amount of the ltc-20 to transfer.
to	No	Address to send to: States the receiving address. If left blank logic will presume that the receiver of the transfer is correct.
fee	No	Transfer fee: For tracking without taproot data purposes only

***fee and to keys were for demo indexing purposes only. Inclusions have no effect on the function nor do they invalidate it.