Game<>Guild: Technical and architecture

In this section:

  • How the Nefta platform functionally works as part of the Game <> Guild <> Scholar ecosystem.
  • What a game does to create the assets and gift to the guild,
  • What the guild does to rent the asset to a wallet, and where Nefta and the Game are involved,
  • What the game has to do in order to get the rented asset to have efficacy within the game, to create a really cool experience for the player.

The high-level flow/architecture;

The game<>guild rental workflow.


The written version:

The game creates assets for the guild

A game partners with a guild, and comes to Nefta.
They want to easily create, deploy, and manage assets in their game. Additionally, they want to offer simple asset rental tools for guilds, to easily manage their scholars.

The game creates an account with Nefta, and creates a special Guild project.
The game uploads the media for the asset, and then customises the smart contract with the Nefta platform. (Really easy stuff).

Once happy, the game gifts all of the assets to the Guild.


The guild rents its assets to scholars/players

The guild logs into the Nefta platform.
Head to Assets, hit import, and connect your metamask.
We automatically import the assets that are in your metamask that were made by the game in the Nefta platform and gifted to you.

The guild can then rent assets individually by clicking on the asset, hitting "rent", and entering a wallet address.

Alternatively, the guild can bulk-rent by heading to "Campaigns" (left-hand navigation), creating an audience of all the addresses they want to send to, and then choosing the asset they want to rent to all of the addresses.


The guild can revoke access to an asset at any point

The guild is in control of the assets.
To revoke access, simply go to "Digital Assets", click "Details" on the asset type you want to revoke access to, find the address you want to revoke access to, and hit "Withdraw".

The wallet that previously had access can no longer be verified with that asset.

πŸ“˜

Note on assets and serials

In our platform, we list an asset type (with an asset ID). This is a singular asset type.

If you click to view "DETAILS" on an asset type, you will see a list of "Ownership IDs".

Ownership IDs are our internal ID for each unique serial.


In other words; rest easy!

You are not renting one asset to lots of wallets. You are in fact renting 1 unique asset to one wallet.

(This is why when you go to revoke access, you will see wallet addresses next to Ownership IDs).


More technical & in-detail:

How asset renting works.

The safest, cheapest, and best way to empower asset rental to scholars is actually by not renting the asset. Every time an asset is rented or returned it costs gas, requires trust, and removes the ability for the guild to mix things up when required.

We've discovered that the preferred solution is:

  • The guild partners with games (or visa versa).
  • The game:
    • Makes the assets and gifts them to the guild,
    • Calls the Nefta API to check if the asset belongs to the wallet (and they know the wallet as it's attached to the in-game player/account ID).
    • Decides the logic in the game to perform if the verification is true.
  • The guild:
    • Owns the asset.
    • Chooses who (what wallet address) should get the benefit of that asset in-game.
    • Decides if and when it wants to withdraw assets from scholars.

The result is cooler games that can use evolvable, timed, and other types of assets in cool ways, the guild has no risk and more control, and scholars get their assets with less friction.

Ultimately, the game calls the Nefta APIs to see if an asset can be used by a wallet ID.
We respond with either yes or no.
The game then does, or doesn't do, what having the asset enables.


The game has to do some stuff to get the asset to work

This is the high-level of what the game has to implement in order to make use of the assets.


Basically:

  • Call Nefta API to check if wallet ID has access to Ownership ID,
  • Game does logic on its end
    • "This wallet has this unique asset ownership ID, which belongs to this type of asset.
    • This type of asset is this type of item in our game.
    • Therefore;
      • Do this thing in the game,
      • Post (POST /asset/:digital_asset_id/evolve) this API to update the traits on the asset (if the asset is an evolving asset and can change. If not, then don't).

Summary:

  • Game makes assets,
  • Game gives assets to the guild metamask,
  • Guild imports assets via the Nefta platform with their metamask,
  • Guild rents assets to wallets.
  • Assets aren't actually sent to wallets - they're owned and kept by the guild,
  • Nefta records what addresses should have access to which assets,
  • The game has to do some work to make the assets work in their game,
  • Once that's done, the player does cool stuff,
  • The game pings our API asking "does this guy have access to this thing",
  • We say yay or neigh,
  • Game stuff happens.