Skip to main content

Introduction to User Token Partition

The User Token Partition provides a robust feature set designed to enable the creation, management, and control of digital rights. This is in contrast to the current generation of blockchain assets, such as NFTs, which are mainly collectibles, and whose value is driven by market dynamics.

In the Alphabill network, tokens are not just collectibles—they are designed to be useful. NFTs can represent more than digital apes or beanie babies. Generally speaking, NFTs are unique tokens that cannot be divided or combined and have some kind of data attached to them. Often this is a URI of something interesting, for example Bored Ape Yacht Club (BAYC) NFTs.

Let's take BAYC #1292 currently for sale:

It is undeniably unique. The Ethereum contract provides excellent cryptographic proof of its provenance, as well as guarantees of scarcity. However, there is very little you can do with it, other than sell it to someone else. Another way to look at it: the only right that "ownership" confers is the right to assign ownership to someone else, that is, to transfer or sell it.

We believe that digital tokens should be capable of much much more. True utility requires a system that has a more robust way to represent different kinds of digital rights programmatically, and also ways for issuers of those rights to limit them. Limitations are necessary so that token issuers can use them to achieve different commercial aims and implement different business models. There are a handful of basic tools that Alphabill tokens have that provide this utility.

Predicates​

Alphabill supports user-defined tokens as first-class citizens, offering a flexible framework for defining custom token types, creating tokens of these types, and transacting with such tokens. This framework uses a system of predicates or clauses to control access to different actions. The main action that can be performed on tokens is the transfer of ownership. The predicate that controls ownership is the bearer predicate or "bearer condition".

Alphabill predicates work similarly to Bitcoin unlock scripts. They are simply functions that accept a number of arguments and they return true or false. For example, a transfer transaction supplies arguments to the current bearer predicate and contains a new bearer predicate, which will be installed upon success. If the arguments result in the function returning true, then that transaction succeeds and the new bearer predicate replaces the old one. During execution of the predicate code, the interpreter also has access to certain global information which depends on the runtime, such as the current block height and the identifier of the token on which the predicate is installed. The predicate does not contain any mutable state and cannot be modified, only replaced.

Token Types​

We already took a look at this famous and expensive ape image. But why is it so expensive anyway? Anyone who has some ether lying around can make more NFTs exactly like these using the same source code, same content, and same everything. Why are these particular ones so valuable? We propose that the reason is that these apes were the first. They are considered special because they kicked off a social trend. Those that came after are just copies without any original thought. You may agree or disagree, but the market is clear. The provenance of NFTs matter. Originality matters. The content of the thought matters, not the content of the URI. The contract that was signed by the original creator's private keys imbues a special significance.

In Alphabill, we have taken the concept of provenance much further, making provenance an extensible first-class citizen on the network. The following applies to both fungible and non-fungible tokens, but for the moment, let's focus on NFTs. Alphabill provides for a system of type inheritance to describe a much richer provenance for tokens. A "token type" definition can be created by anyone. It is, itself, similar to a token in some ways. It occupies a unique space in Alphabill's User Token Partition state; it has properties, but unlike tokens, it cannot be bought or sold. Instead, it can be inherited from.

Token types have three additional predicates (or clauses) that users can set and which are used by the type creator to define their inheritance behavior:

  • subtype: this predicate must be satisfied in order to create a new inherited token type. This can be used to define the conditions under which new token types can inherit from this type. This can be used to create controllable hierarchies of token types.

  • mint: this predicate must be satisfied in order to create tokens of a given token type. Some token types may exist only to be subtyped; others might exist only to be minted; and still some might do both. This is obviously useful to control production and regulate scarcity, implement new supply, etc. Mint clauses are inherited by all tokens that inherit from these types.

  • bearer: this predicate defines additional conditions of transfer imposed by the token type. This predicate must be satisfied in addition to the main bearer predicate, defined above. Unlike the main bearer predicate, the inherited bearer predicate is immutable so it can be used by token designers to impose transfer restrictions for tokens that are derived from the original token type. The inherited bearer predicate applies to any tokens of the defined type and any tokens that belong to types that inherit from the defined type.

    The inherit bearer predicate applies to a) any tokens of this type, and b) any tokens of any type that inherit from this type.

    The purpose of the inherit bearer clause is to provide for a way for token type creators to impose restrictions or control on how tokens that wish to inherit from their types can be transferred. Since it's possible to inherit many levels deep, there may be many, chained, inherit bearer clauses that must all be satisfied in order to transfer a token.

    There are numerous reasons that this might be useful, including:

    • Licensing of popular token types.
    • Creation of token hierarchies.
    • Establishing provenance of tokens.
    • Implementing fine-grain roles and permissions.
    • Creating whitelists or blacklists of owners.
    • Many others, still to be explored.

Token Mutability​

Still, what can you do with NFTs? For the vast majority of NFTs you can just buy them, sell them, and prove you own them. They lack further functionality. That's why we gave NFTs on Alphabill an additional "data" field that can be changed over time. This mutable data can be changed, based on satisfying an additional predicate called the data update predicate. This works in a similar way to other predicates: a user sends a transaction order, which supplies arguments to the predicate, and new data that should replace the old data. If the predicate returns true, then the data is changed as a result of the transaction.

Importantly, the data update predicate does not need to be the same as the bearer predicate. This means that the owner of the token is able to give other users permission to change the data on a token they own.

Another key concept is that the current contents of the data field itself, as well as the proposed new contents of the data field are both available during the evaluation of the data update predicate. This predicate can be considered a function, where the user supplied arguments, the previous data field, and proposed new data field are all within the scope of the function body.

The impact of this is that you can use the data field to implement state machines, or other automata. An example of a use case where this might be useful could be in trade finance. A token represents a shipment. The URI points to immutable documentation about the contents, original ownership, and tax and regulatory information about the shipment. The data field is used to implement a state machine, which describes the transfer and responsibility for the goods, along the supply chain. The ownership of the token itself represents ownership of the goods being shipped, and lending—either on a centralized or decentralized financial system—can take place using the token as collateral.

Finally, the data update predicate is also an inheritable feature. NFT token types have an additional predicate called the data predicate. It works the same way as the other inherited predicates, in that it is defined as part of the token type, and all tokens of that type inherit it. It is also subject to the same subtyping rules as the inherited bearer predicate, so parent's data predicates are inherited by all child token types, and all tokens that are minted from them.

Conclusion​

Putting together the features of inheritance and mutability allows users to create a rich ecosystem of useful tokens that can be used by companies, individuals, and governments to represent real-world processes and use cases. Tokens can be directly used for the exchange of digital rights, goods and services, and they can be programmed to follow business processes that meet the requirements of enterprises and regulation. All of this can be executed in a trustless manner.

The Alphabill token type system is flexible, robust, and offers many new techniques for token creators to provide additional functionality for their tokens. This allows the Alphabill User Token Partition to model a wide range of real-world behaviors, and enable use cases that unlock economic value, instead of relying on pure speculative interest.

While only a few different types of predicates are currently available, in the near future, we will be migrating to a fully customizable WebAssembly-based predicate language, where the possibilities will be limited only by the developer's imagination.

Next Steps​

Start with creating your own fungible and non-fungible token types using some of the User Token Partition inheritance features. Then move on to minting new tokens based on these types, and finally transferring tokens from one account to another.