P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes

Abstract

The BRC-46 architecture for digital assets stored within wallet baskets enables a wide range of use cases. However, it lacks support for more than a rudimentary permission system. Wallets can grant applications blanket access to basketed assets, or deny access entirely, but cannot make insightful decisions based on the specific assets stored, their output scripts, or the tokenized value they represent. To support the future development of new permission schemes covering fungible and non-fungible digital assets within wallets, we propose reserving certain basket identifiers to prevent their use by applications and ensure compatibility with future standards.

Motivation

The motivation for this proposal is to future-proof the BRC-46 architecture by enabling the seamless integration of new permission schemes applicable to assets stored in or retrieved from wallet-managed UTXO baskets. By specifying reserved identifiers, we can ensure that new security and permission paradigms can be implemented without conflicts or unintended behavior.

Specification

To accommodate future basket permission schemes, wallets must reject any operation requests made under basket IDs beginning with p (a lowercase “p” followed by a space).

Future Scheme Identifiers

Future permission schemes must define their ID formats, as follows:

• The scheme IDs cannot contain spaces.
• The basket IDs must start with p , followed by the scheme ID, a space, and the rest of the basket identifier.

Example Format

A basket ID such as p dollarToken xxxxx could represent a specific token type (e.g., tokenized dollars), where:

• p designates an alternative permission scheme.
• dollarToken identifies the permission scheme.
• xxxxx forms the basket ID under the alternative scheme.

Basket ID Parsing and Rules

Wallets must differentiate between standard and alternative permission schemes by recognizing the p prefix followed by a distinct, space-free scheme ID. To ensure unambiguous parsing.

Upon recognizing a basket ID structured as p <scheme ID> <rest of the ID>, wallets may apply the specific rules defined by the scheme associated with the scheme ID. These rules could define:

• Constraints based on specific locking scripts or script templates of UTXOs.
• The conditions under which operations can be executed.
• Mechanisms for allowing applications to access only a certain set number of only a specific asset type, according to the rules of some tokenization protocol, overlay service or script template.
• Specific counterparty requirements and other customizable permission attributes.

Reserved Structure

To maintain clarity and prevent conflicts:

• Basket IDs beginning with p must be reserved for future use.
• Wallets must reject operations involving such IDs unless they explicitly support the scheme ID.
• A space must immediately follow the scheme ID to separate it from other elements.

Extensibility Beyond Current Paradigms

This specification allows future permission schemes to extend beyond current BRC-46 models (e.g. BRC-73 paradigms), enabling flexible and innovative wallet permissions that evolve with user and application needs.

For example, a wallet could allow access to a maximum of 10 dollars of tokenized fiat money per month within an application.

Conclusion

By reserving basket IDs starting with p and specifying rules for future permission schemes,this specification ensures forward compatibility and robust wallet permission functionalities. It enables seamless integration of new schemes without disrupting existing applications or introducing parsing ambiguities.