Staking(3,3) on BRC-20

This documentation provides an overview of the staking mechanism for BRC-20 tokens.

Introduction

BRC-20 started as an experiment which got widely adopted in the community today. A lot of improvements have been suggested by a lot of awesome devs. Here we are providing you a detailing on how STAKING can/will be implemented for BRC-20.

Please note that this standard is very early and the idea was shared on 14th May by @0x_web3 twitter handle. It can change as the ecosystem gets more mature!

Note: The staking enabled BRC-20 tokens are BACKWARD COMPATIBLE. Means, tokens can be bought/sold/visualised on existing tools/infra supporting BRC-20 ecosystem.

Permissible Operations for (3,3) on BRC-20

There are 4 possible 'op' (operations) to enable staking on BRC-20.

1. Deploy

2. Mint

3. Transfer

4. Untransfer

Deploy

Deploy method is used to deploy a BRC-20 token with staking support. Here is the JSON format for inscribing ‘deploy’

{
"p":"brc-20",
"op":"deploy",
"tick":"bYLD",
"max":"10000000",
"lim":"10000",
"yield": {"6000": "0.0007","8000": "0.0002", "1000000":"0.00002"}
}

Everything mentioned here is referred from domo’s gitbook (existing BRC-20 standard) except ‘yield’.

What does yield represent?

‘yield' indicates appreciation of tokens (per block). It's a nested JSON object where key "6000" represents first 6000 blocks and its yield, next 8000 blocks, and so on. Example: Holding 1000 $bYLD tokens in a staking vault for 100 blocks gives you 1070 tokens (70 reward).

Key	Required?	Description
p	Yes	Protocol: Helps other systems identify and process brc-20 events
op	Yes	Operation: Type of event (Deploy, Mint, Transfer, Untransfer)
tick	Yes	Ticker: 4 letter identifier of the brc-20
max	Yes	Max represents the maximum mintable supply. NOTE: The total supply (max supply + staking rewards) will be inflationary just like any staking token on any chain.
lim	No	Mint limit: If letting users mint to themselves, limit per inscriptionNextStaking & Unstaking of BRC-20 tokens
dec	No	Decimals: set decimal precision, default to 18
deploy	No	Nested Json object specifying the yield rates for first x blocks, then y blocks etc. If this key is mentioned, it means stalking is allowed for the ticker.

Note: The value in nested json for set of blocks is reward per token per block.

Mint

Mint works exactly same as existing BRC-20 tokens.

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)

Transfer

Transfer works exactly same as existing BRC-20 tokens

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.

Untransfer

Note: Untransfer works only for staked tokens

Untransfer is a new operation compared to 3 existing operations from BRC-20 tokens. Given there are no smart contracts in BRC-20 ecosystem, we can not have locking/staking of tokens in any code. To enable STAKING, we will introduce a common staking address (similar to burn address) whose keys will not be accessible to anyone. Whenever anyone inscribes untransfer and sends it to STAKING address, it would be as given below:

{
"p":"brc-20",
"op":"untransfer",
"tick":"bYLD",
"txn":"c63ac7663b77b01dc941fc990caf04bb48cb9aeeade8ddi0"
}

Key	Required?	Description
p	Yes	Protocol: Helps other systems identify and process brc-20 events
op	Yes	Operation: Type of event (Deploy, Mint, Transfer, Untransfer)
tick	Yes	Ticker: 4 letter identifier of the brc-20
txn	Yes	Inscription id of the ‘transfer’ which was sent to STAKING address

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 not staked and untransfer function is wasted). Some ordinal wallets generate a different address each time, make sure to send to the address that holds 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 "$bYLD", and the holder then inscribes a transfer function of 700 "$bYLD". 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 "$bYLD", 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

• If user sends the transfer inscription to STAKING address, then the balance will be deducted from the wallet. Eg. If you had 100 tokens and sent 30 tokens to STAKING address, your wallet will show 70 tokens. On BitStake dashboard, you can see the staked tokens and their balance (including rewards). When you send untransfer call, the balance (30+ some rewards) will get back to your wallet and it will show (100+ rewards) as your balance. Unisat might not support it as of now but they might very soon start indexing in a way catering to the staking process.