Yokefellow - Blog
Welcome to Yokefellow: Buckets, NFTs, and Apps That Work Together
Yokefellow is a system for building bucket-backed apps where NFTs can carry access, claims, permissions, proof, crafting inputs, and other usable rights.
At the center of Yokefellow is a simple idea: apps should not have to rebuild participation, NFT utility, records, and proof from scratch every time. A bucket is the programmable object underneath the experience. It holds the structure the app needs: rules, balances, NFT actions, permissions, activity, records, and proof.
A bucket is the programmable object underneath the experience. It holds the structure the app needs: rules, balances, NFT actions, permissions, activity, records, and proof.
The bucket page is the public home for that object. It explains what the bucket is, who is behind it, what users can do, what NFTs may be created or used, what rules apply, and what records or proof are attached.
The app or surface is where the user actually interacts.
That surface might be a game, event page, access portal, product claim flow, auction, market, builder tool, creator space, or another experience. The user does not need to think about the bucket as an abstract technical object. The user sees the experience. The experience talks to the bucket underneath.
That is the basic model:
- A user opens an app or surface.
- The surface reads a bucket.
- The bucket defines what actions are available.
- Those actions can create, check, transfer, burn, redeem, refill, update, or use NFTs.
- The bucket page keeps the public explanation and record attached.
That is Yokefellow.
Why This Matters
Most apps that use NFTs have to stitch the important pieces together themselves.
- One tool handles the website.
- Another handles payment.
- Another handles NFT minting.
- Another handles access.
- Another handles user records.
- Another handles proof.
- Another handles updates or fulfillment.
Yokefellow is built so those pieces can connect through one bucket-backed structure.
The point is not only to mint NFTs. The point is to make NFTs useful inside real app experiences, while keeping the rules, ownership, actions, and records easier to follow.
A creator, builder, team, or community should be able to launch an experience where the rules, wallet actions, NFTs, permissions, redemptions, and proof are connected from the start instead of being patched together afterward.
Buckets
A bucket is the object underneath a Yokefellow-powered experience.
It can hold the rules for the experience, the NFT actions users can take, the records of what happened, and the current state of the surface built on top of it.
A bucket can support many kinds of experiences because the bucket is not locked to one interface. One bucket might power an access portal. Another might power a game. Another might power a product claim. Another might power a creator tool, event page, market, or other app surface.
The surface can change. The bucket is the structured object underneath.
Bucket Pages
The bucket page is the public listing and record for a bucket.
Think of it like the app store page for a bucket-backed experience, except it can also show records and proof.
A good bucket page should explain:
- what the bucket is
- who is behind it
- what app or surface it connects to
- what users can do
- what NFTs may be created or used
- what those NFTs mean
- what rules or limits apply
- what state the bucket is in
- what records or proof exist
The bucket page should not be only marketing copy. It should help the user understand the experience before they act and check the record after something happens.
Actions, Rules, and NFTs
A bucket can show users actions.
A user might click to get access, craft an upgrade, redeem a claim, earn a badge, enter a private tool, unlock a role, or prove they qualify for something else.
Inside the system, these actions have rules. The rule says what the user has to do and what the app should create, check, change, or use.
That is the clean way to understand it:
- The action is what the user does.
- The rule defines how that action works.
- The NFT is the object the action creates, checks, changes, burns, redeems, refills, or uses.
For example, a “Get Access” action might create an access NFT.
A “Craft Upgrade” action might check that the user owns two NFTs, then create a third.
A “Redeem Claim” action might check that the user holds a claim NFT, then mark that claim as used.
A “Monthly Benefit” action might check whether the NFT has already been used this month.
A “Permission” action might check whether the wallet holds the NFT required to use a tool or role.
The user does not need to learn every internal word first. They need to understand what the action does, what NFT is involved, and what record proves it happened.
What NFTs Can Do in Yokefellow
In Yokefellow, NFTs are not only collectibles or profile pictures.
A bucket can use NFTs as working objects inside an app or surface. The NFT might be something a user receives, something the app checks, something the user redeems, something that refills over time, something that upgrades, something that gets burned, or something that unlocks another path.
An NFT can work like an access pass.
A user holds the NFT, and the connected app checks the wallet before opening a private area, event stream, tool, room, game level, or member-only surface.
An NFT can work like a claim.
A user holds the NFT because it represents something they can redeem: a product, appointment, ticket, service, digital item, physical item, discount, meal, repair, lesson, download, or other benefit.
An NFT can work like a refillable benefit.
A holder might be able to redeem once per month, once per year, once per season, once per event, or on some stranger schedule the bucket defines. A coffee shop could issue a monthly drink pass. A gym could issue a yearly training perk. A creator could issue a seasonal download claim. A witch could sell a Moonbrew NFT that refills only on the full moon.
The point is not the theme. The point is that the NFT can carry a rule the app knows how to check.
An NFT can work like an ingredient.
A game, builder tool, or creative surface could let a user combine NFTs they already hold into something new. One version lets the user keep the original NFTs and simply prove they hold them. Another version burns or consumes the old NFTs to create the new one.
An NFT can work like a permission key.
A holder might be able to post, review, moderate, build, vote, enter a workspace, manage a surface, use a tool, or take another action inside a defined bucket-backed app.
An NFT can work like proof.
It can show that a user participated, won, completed something, supported something, attended something, earned something, or qualified for something.
The important part is that the NFT is not floating by itself. The bucket explains what the NFT means. The app or surface uses it. The chain lets users check the token facts: whether it exists, who holds it, when it minted, whether it transferred, and whether it was burned or changed through an onchain action.
Example: Access
Imagine an app with a private workroom, event stream, creator tool, or gated game level.
The bucket page explains what the access is and what NFT unlocks it.
The user uses the surface to get the access NFT.
The app checks the user’s wallet. If the wallet holds the correct recognized NFT, the app unlocks the gated area.
This is stronger than a private allowlist because the access object can be checked onchain. The NFT exists in a collection. It has an owner. It has a mint history. If it transfers, that transfer can be seen. If it is burned or changed through the designed path, that can be reflected too.
The app still explains what the access means, but the token facts are not only a private website claim.
Example: Redeemable and Refillable Claims
A bucket can create NFTs that represent claims.
A claim is something the holder can use or redeem. It might be simple, like one ticket to one event. It might be practical, like one product pickup. It might be recurring, like one benefit per month. It might be strange and themed, like a potion shop that lets holders claim one lunar brew every full moon.
The bucket page explains the claim.
It should tell users what the NFT can be used for, who is responsible for honoring it, whether it can transfer, whether it expires, whether it refills, how often it can be used, and what happens after redemption.
The connected surface handles the actual use.
When the holder wants to redeem, the app checks the wallet for the NFT. Then it checks the rules attached to that NFT.
- Is the claim unused?
- Has this month’s benefit already been claimed?
- Has the yearly refill reset yet?
- Is the token expired?
- Was it transferred?
- Was it burned?
- Does this wallet still hold it?
That is where Yokefellow becomes more useful than a screenshot, spreadsheet, coupon code, or private promise.
- The NFT gives the claim a durable object.
- The bucket gives the claim its public meaning.
- The app gives the holder a place to use it.
- The record shows what happened after it was used.
A redeemable NFT could be single-use.
A refillable NFT could refresh on a schedule.
A craftable NFT could be created from other NFTs.
A permission NFT could unlock a role or tool.
A proof NFT could show that something happened.
Those are all different uses of the same basic idea: the NFT is a programmable object that a bucket-backed app can recognize and use.
Example: Crafting
Now imagine a game or builder surface where a user can create a new NFT from NFTs they already hold.
The bucket page explains the recipe.
The surface checks the user’s wallet.
The user has NFT A and NFT B.
The action creates NFT C.
There are two basic versions of this.
In a hold-based craft, the user keeps NFT A and NFT B. Holding them unlocks the ability to create NFT C.
In a burn-based craft, NFT A and NFT B are consumed. They are burned or used up, and NFT C is created from them.
That matters because NFTs in Yokefellow are not only collectibles. They can become ingredients, requirements, proof objects, upgrade paths, or permissions inside an app.
The result can be checked because the input NFTs, output NFT, mint event, burn event where applicable, owner, collection, and token history can be inspected onchain.
Example: Permissions
Some NFTs can act like permission keys.
A permission NFT might let someone enter a tool, post in a controlled area, review submissions, manage part of an app, unlock a creator feature, or access a specific role.
The app checks whether the wallet holds the right NFT.
The bucket page explains what that permission means and where it applies.
This does not mean every NFT works everywhere. Scope matters. A permission NFT might work only inside one bucket, one app, one event, one tool, or one defined surface.
That is why the bucket page matters. It tells users what the NFT actually does.
Onchain Verification
Yokefellow should not ask users to trust only what a website says.
When an NFT is issued through a recognized Yokefellow collection, the important token facts can be checked onchain:
- the collection contract
- the token or token class
- the wallet that holds it
- the mint event
- the transfer history
- burn events where relevant
- the transaction that created or changed it
The chain answers questions like:
- Does this NFT exist?
- Who holds it?
- When was it minted?
- Did it transfer?
- Was it burned?
- What transaction created or changed it?
The bucket and app answer a different question:
What does this NFT mean here?
Those two layers work together. The chain verifies the token facts. The bucket and surface explain the meaning.
What Yokefellow Is Not
Yokefellow is not just an NFT minting site.
Minting is only one possible action. A Yokefellow surface can also check NFTs, require NFTs, burn NFTs, transfer NFTs, redeem NFTs, refill NFTs, update NFTs, or use NFTs as inputs for new actions.
Yokefellow is not just a token.
YES supports the economic layer of the system, but Yokefellow is bigger than YES.
Yokefellow is not one app.
It is a system for building many bucket-backed surfaces that can use NFTs, rights, records, proof, and value movement in different ways.
The Short Version
Yokefellow works like this:
- A bucket is the programmable object underneath an experience.
- A bucket page explains that object and keeps its record.
- A surface or app is where the user interacts.
- The bucket defines the actions users can take.
- Those actions can create, check, transfer, burn, redeem, refill, update, or use NFTs.
- Onchain records let users verify token facts like minting, ownership, transfers, and burns.
- The bucket and app explain what those token facts mean inside the actual experience.
That is Yokefellow: a system for building apps where NFTs are not just collectibles, but usable objects connected to rules, actions, records, and proof.
Start here:
Related posts
More to read next.
