Craftable Token

A general class of tokens that could be either Craftable Inputs or Outputs

How can a token become Craftable?

To make your ERC1155 become a craftable token, the contract for the token must:

  1. Extend your token from either or both abstract classes. Depending on what you extend, your token can be used in different roles:

  1. Compose the Definition Metadata file and host it with a publicly accessible URI. The definition metadata will contain the necessary informations to other games and to the Craftware Crafting Web-app about the token attributes.

  2. Implement the virtual functions from the inherited contracts you added. This is necessary to link the internal functionality of your tokens to the Crafting Protocol. Functions involve the defining how to read the attributes in order, generating the metadata URI for OpenSea, ...

  3. Updating the minting for your tokens to assign classes for them. (More on that here).

  4. Deploy your token to the blockchain of choice.

What common functionality exist for a Craftable Token?

Both CraftableIn and CraftableOut inherit from a base contract CraftableBase where functions necessary for both are defined.

craftable/CraftableBase.sol
contract CraftableBase is ICraftableBase, ERC1155 {
  uint256[] _classes;

  // the definition Uri contains important information 
  // like the attribute names and their types
  string _defUri;

  function ownsEnough( ... ) public view returns (bool) {
    return balanceOf(user, _id) >= balance;
  }

  function classes(uint256 _id) ...

  function defUri() ...
}

Constructor

Any contract inheriting from one of the craftable must provide the URI for the Definition Metadata file they host. for example:

Falafel.sol
contract Falafel is ..., CraftableIn {
    ...
    constructor( ... ) CraftableIn ( <ERC1155 metadata base URI>, <Definition metadata URI> ) { ... }

Classes

We propose a new dimension of ERC1155 tokens. We propose that each token minted in the ERC1155 contract should be assigned a class, so that tokens from the same class have the same attribute sets. This is important for crafting rules, because they need to know what is the set of attributes associated to a token.

For example, for an ERC1155 token contract clothes.sol describing clothes in a game, it could mint hats and pants. But, hats have different attribute set (head_size, is_wool) than pants (length, material, size). As ERC1155 allows us perfectly to mint both in the same contract, we can assign all hats to class 1 and pants to class 2. If not, when a user inputs a token from clothes.sol , we might not know whether it's a hat or pants and their attribute sets.

Classes are represented as lists

CraftableBase.sol
2 uint256[] _classes;

The class of the token is added automatically after minting it. for example:

clothes.sol
uint256 public HAT_CLASS = 1;
uint256 public PANT_CLASS= 2;

mintHat( ... ) {
    _tokenIds.increment();
    ...
    _classes.push(HAT_CLASS);
}

mintPant( ... ) {
    _tokenIds.increment();
    ...
    _classes.push(PANT_CLASS);
}

Definition URIs

The definition URIs are essential to define the various classes and their required attributes. This allows other games, players, and the craftware web-app to understand the values for the attributes stored in lists.

Docs

Functions
ownsEnough(address user, uint256 _id, uint256 balance) view

Returns true if the user has a balance of token _id greater than or equal to balance.

classes(uint256 _id) view

Returns the class of token of ID _id.

defUri()

Returns the URI for the definition metadata JSON.

Last updated