OIP - Orc Improvement-proposal

Legacy Page

All OIPs have been moved to the OIPs page. This page is view only and no longer active.

OIP Proposal Reason Status

OIP	Proposal	Reason	Status
OIP-1	Change: `p` protocol to be required. Explicitly declare protocol, eg. orc-20 or orc20 (case-insensitive). New protocols can be included, eg. src-20, xrc-20 in future.	Protocol name help index services to identify and implement specific rules of new protocols built on top of ORC-20.	Accepted (May 6, 2023)
OIP-2	Change: `op` operations to allow both `send` and `transfer`	Making ORC-20 send inscription back compatible with BRC-20.	Accepted (May 7, 2023)
OIP-3	Change: `id` to use inscription number of the deployment Note: ORC-20 minted before May 8, 2023 using Tick ID are still valid.	Initial thought was to compress the json file of the ORC-20 inscriptions. However, inscription number helps query inscriptions much faster.	Accepted (May 8, 2023 - Block #788836)
OIP-4	Change: add `list` operation to include the collection of inscription numbers	Deployer inscribes listing event to help holders and marketplaces identify a collection of authentic inscriptions.	Accepted (May 9, 2023)
OIP-5	Change: make `mint` and `send` inscriptions reusable by @Cirus001 (https://twitter.com/Cirus001/status/1654766721482522624)	Currently `transfer` inscriptions of BRC-20 occupy too much Bitcoin and ordinals space, and uses too much inscription fees and gas. Making mint and send inscriptions reusable could save precious Bitcoin space, and ultimately stop wasting gas and make transaction faster.	Accepted (Jun 2, 2023)
OIP-6	Change: Upgrade of deployed tokens require the deployer to send that minted Upgrade Inscription to a designated wallet address, e.g. a burn wallet. by @Cirus001 (https://twitter.com/cirus001/status/1655217736388317185?s=46&t=KNkpTgZIf3A2ObCUq8z2fg)	Upgrade is only valid after the deployer send that upgrade function to a designated wallet address, e.g. a burn wallet. The upgrade requires a signature from the deployers wallet, so no one expects the private key holders can make changes to the deployed tokens. (Note: Same principle applies to any operations require deployers' signature, eg. list, migrate, upgrade)	Accepted (Jun 7, 2023)
OIP-7	Change: improvement of indexing: Automatic index all existing BRC20 tokens as valid ORC20 tokens. by @Cirus001 (https://twitter.com/Cirus001/status/1655644993904861186)	Give up the 4 Chars naming space, And automatically add ORC20 tokens balances of the same 4 chars ticker to all BRC20 holder’s addresses.	In Progress
OIP-8	Use the self ID system in parallel with the Inscription number as ID proposal. Deployer can pick any ID number that’s lower than the current highest inscription number, if they are not already taken. One deployed token will have two IDs that are both accepted. by @Cirus001 (https://twitter.com/Cirus001/status/1664337264204476416)	The original design allows any number to be used as ID, this is not a hard fork if it revert back. If deployed without any ID number, default the token ID to inscription number only. If deployed with an ID that’s already taken, default the token ID to inscription number only. Self ID is important, because inscription numbers are not onchain data that’s immutable. It allows more personalized choices. Limiting the choices to be lower than the highest inscription number, will make sure all future deployer will at least have 1 functioning ID number. All current ORC20 deployers should have at least 1 ID number that’s still valid. All minting and transferring of ORC20 tokens with both ID systems are all still valid without any need for block height checks.	In progress
OIP-9	ORC-20 based domain names Enable anyone to deploy an ordinal domain suffix. The deployer can deploy any domain names like .orc, .orcsats, .doge, .bit, and .oid etc. Indexers can utilize the existing ORC-20 standard for ORC-20 based domain names.	Further decentralize, democratize, and regulate the domain registry process on Bitcoin.	Accepted (Jun 3, 2023)
OIP-10	To split a balance of existing 'mint' & 'send' inscriptions, the holder must send the inscription to be split to a designated 'split' burn wallet. This design is important in preventing double-spending. (https://twitter.com/Cirus001/status/1666370963351699456)	Sending the inscription to this 'split' burn wallet will not transfer the balance to it, but creating a floating credit in the holder's wallet to enable creating new valid transfer inscriptions. Transfer of tokens will only require minting/sending 1 single valid inscription.	In Progress
OIP-11	In the last transaction step, send "remaining balance" must explicitly define amount and "nonce: -1". This enables the reuse of the remaining balance inscription with minimum risk of accidentally spending any unexpected amount. The "remaining balance" can be reused or further split into smaller "inscription amounts". Nonce "-1" requires least amount of code changes. Before OIP-11 pass, indexers are expected to ignore sending "remaining balance" inscription in a transaction. If the amount doesn't equal to the remaining balance then this partial transaction will fail, as a result the whole transaction will not complete. For example, if the remaining balance is zero, you must explicitely specify zero amount; if 100, specify 100.	The current approach of the final step in a TX allow account owner to inscribe "send remaining balance" to complete a series of partial transactions without specifying any amount. For example, user can cancel any preceding partial TX before the final step. However, by design you should not transfer balance by sending this "send remaining balance". Currently indexers might have different interpretation and implementation. Some indexer might allow "send remaining balance" in cascading transactions. This might cause inconsistency between indexers.	In Progress

OIP-1

Change: p protocol to be required. Explicitly declare protocol, eg. orc-20 or orc20 (case-insensitive). New protocols can be included, eg. src-20, xrc-20 in future.

Protocol name help index services to identify and implement specific rules of new protocols built on top of ORC-20.

Accepted (May 6, 2023)

OIP-2

Change: op operations to allow both send and transfer

Making ORC-20 send inscription back compatible with BRC-20.

Accepted (May 7, 2023)

OIP-3

Change: id to use inscription number of the deployment

Note: ORC-20 minted before May 8, 2023 using Tick ID are still valid.

Initial thought was to compress the json file of the ORC-20 inscriptions. However, inscription number helps query inscriptions much faster.

Accepted (May 8, 2023 - Block #788836)

OIP-4

Change: add list operation to include the collection of inscription numbers

Deployer inscribes listing event to help holders and marketplaces identify a collection of authentic inscriptions.

Accepted (May 9, 2023)

OIP-5

Change: make mint and send inscriptions reusable by @Cirus001 (https://twitter.com/Cirus001/status/1654766721482522624)

Currently transfer inscriptions of BRC-20 occupy too much Bitcoin and ordinals space, and uses too much inscription fees and gas. Making mint and send inscriptions reusable could save precious Bitcoin space, and ultimately stop wasting gas and make transaction faster.

Accepted (Jun 2, 2023)

OIP-6

Change: Upgrade of deployed tokens require the deployer to send that minted Upgrade Inscription to a designated wallet address, e.g. a burn wallet. by @Cirus001 (https://twitter.com/cirus001/status/1655217736388317185?s=46&t=KNkpTgZIf3A2ObCUq8z2fg)

Upgrade is only valid after the deployer send that upgrade function to a designated wallet address, e.g. a burn wallet. The upgrade requires a signature from the deployers wallet, so no one expects the private key holders can make changes to the deployed tokens. (Note: Same principle applies to any operations require deployers' signature, eg. list, migrate, upgrade)

Accepted (Jun 7, 2023)

OIP-7

Change: improvement of indexing: Automatic index all existing BRC20 tokens as valid ORC20 tokens.

by @Cirus001

(https://twitter.com/Cirus001/status/1655644993904861186)

Give up the 4 Chars naming space,

And automatically add ORC20 tokens balances of the same 4 chars ticker to all BRC20 holder’s addresses.

In Progress

OIP-8

Use the self ID system in parallel with the Inscription number as ID proposal.

Deployer can pick any ID number that’s lower than the current highest inscription number, if they are not already taken.

One deployed token will have two IDs that are both accepted.

by @Cirus001 (https://twitter.com/Cirus001/status/1664337264204476416)

The original design allows any number to be used as ID, this is not a hard fork if it revert back.

If deployed without any ID number, default the token ID to inscription number only.

If deployed with an ID that’s already taken, default the token ID to inscription number only.

Self ID is important, because inscription numbers are not onchain data that’s immutable.

It allows more personalized choices.

Limiting the choices to be lower than the highest inscription number, will make sure all future deployer will at least have 1 functioning ID number.

All current ORC20 deployers should have at least 1 ID number that’s still valid.

All minting and transferring of ORC20 tokens with both ID systems are all still valid without any need for block height checks.

In progress

OIP-9

ORC-20 based domain names

Enable anyone to deploy an ordinal domain suffix.

The deployer can deploy any domain names like .orc, .orcsats, .doge, .bit, and .oid etc.

Indexers can utilize the existing ORC-20 standard for ORC-20 based domain names.

Further decentralize, democratize, and regulate the domain registry process on Bitcoin.

Accepted (Jun 3, 2023)

OIP-10

To split a balance of existing 'mint' & 'send' inscriptions, the holder must send the inscription to be split to a designated 'split' burn wallet.

This design is important in preventing double-spending. (https://twitter.com/Cirus001/status/1666370963351699456)

Sending the inscription to this 'split' burn wallet will not transfer the balance to it, but creating a floating credit in the holder's wallet to enable creating new valid transfer inscriptions.

Transfer of tokens will only require minting/sending 1 single valid inscription.

In Progress

OIP-11

In the last transaction step, send "remaining balance" must explicitly define amount and "nonce: -1". This enables the reuse of the remaining balance inscription with minimum risk of accidentally spending any unexpected amount. The "remaining balance" can be reused or further split into smaller "inscription amounts". Nonce "-1" requires least amount of code changes. Before OIP-11 pass, indexers are expected to ignore sending "remaining balance" inscription in a transaction. If the amount doesn't equal to the remaining balance then this partial transaction will fail, as a result the whole transaction will not complete. For example, if the remaining balance is zero, you must explicitely specify zero amount; if 100, specify 100.

The current approach of the final step in a TX allow account owner to inscribe "send remaining balance" to complete a series of partial transactions without specifying any amount. For example, user can cancel any preceding partial TX before the final step. However, by design you should not transfer balance by sending this "send remaining balance". Currently indexers might have different interpretation and implementation. Some indexer might allow "send remaining balance" in cascading transactions. This might cause inconsistency between indexers.

In Progress

PreviousOIP-10

Last updated 9 months ago