Yokefellow - How Yokefellow Works
Rights & Offerings Paper
The user-facing meaning of offerings, rights, carriers, scope, constraints, fulfillment, and NFT-backed outputs.
Yokefellow Rights & Offerings Paper
1. Why Rights Matter
Yokefellow uses the language of rights because participation is supposed to lead to something a person can actually understand. If a user supports an initiative, enters an offering, earns an outcome, or is granted access through a bucket, the platform should be able to say clearly what that person may receive and what that result is supposed to mean. Without that clarity, participation becomes easy to market but hard to trust.
A right is the clearest frame because it keeps the focus on user-facing value instead of on the container alone. The NFT matters, but the NFT is not the whole explanation. The user should be able to understand what they may do, use, access, prove, control, redeem, or carry forward before they participate, not only after they are already holding an object.
This also matters because rights on Yokefellow are broader than one narrow category. A right may unlock entry, participation, competition, posting authority, naming authority, status, tool use, digital goods, product claims, role-based utility, or independent-contractor work. The platform is stronger when those things can be described in plain language instead of being flattened into generic token talk.
Most importantly, the rights frame helps keep expectations honest. A right can be real without meaning ownership in Yokefellow itself. It can be valuable without being permanent. It can be meaningful without being unrestricted. The point of rights language is not to inflate what the user receives. It is to describe it accurately enough that the user can understand it before entering the path.
That matters especially on Yokefellow because the platform is not only a storefront and not only a token surface. It is a structured participation system. People may buy, earn, request, apply for, be granted, redeem, use, hold, consume, transfer, display, prove, or exercise what they receive in different ways. Rights are the user-facing layer that keeps those differences legible.
2. The Core Frame
On Yokefellow, a right is a programmable entitlement.
In many cases, that entitlement is carried by an NFT. But the NFT alone does not fully define the right. The right is shaped by the full stack around it:
the bucket context that made the path meaningful
the offering path that made it available
the collection and class it belongs to
the transfer, burn, and supply rules attached to it
the selection and fulfillment structure that resolved into it
the controls attached to the carrier
the main-app bucket bindings that may connect it to a bucket surface
the permissions, capabilities, metadata, and application code that interpret it in practice
That means a right should not be read only as a token and not only as a label. It should be read as an entitlement carried by a configured system object inside a specific context.
This is one of the most important things to understand about Yokefellow. The same NFT standard can carry very different rights. One NFT may function as event access. Another may function as a posting right on a bucket. Another may function as a competition entry. Another may function as a tool-use entitlement. Another may function as a redeemable product claim. Another may function as a work or operator role. The carrier can look similar while the right remains different.
That is why this paper keeps the right in front. The user-facing meaning matters more than the container alone. The container is how the entitlement is carried. The right is what the user may actually receive.
3. What an Offering Is
An offering is the structured way a bucket makes participation or rights available. It is the object a user encounters when the bucket is saying, in effect: this is a path you can enter, and this is the kind of result that path may lead to.
That is why Yokefellow uses the word offering instead of older reward or claim language. An offering is broader than a sale, broader than a giveaway, and broader than a mint. It is the platform’s structured participation surface.
An offering does two jobs at once. For the user, it is the visible participation path. For the system, it is the structure that holds the terms of that path. It tells the user whether they are buying something, earning something, requesting something, applying for something, or being granted something. It also tells the system how that path should resolve.
An offering should therefore not be treated as a generic product listing. Some offerings are priced. Some are free. Some are direct. Some are review-dependent. Some are immediate. Some create pending state first. Some resolve into one known class. Some resolve into a selected class or a weighted pool. The offering is the structured path above those differences.
Most importantly, an offering is not automatically the right itself. The offering is the path. The right is the user-facing value that may be received through that path. Keeping those ideas separate helps the platform stay legible.
4. What a Right Is on Yokefellow
A right on Yokefellow is the user-facing value a person may receive through an offering. That value can take the form of access, participation ability, utility, status, permission, posting authority, naming authority, product claim, work authority, or another defined benefit tied to the bucket and the offering that issued it.
A right is therefore not the same thing as the bucket, not the same thing as the offering, and not automatically the same thing as the NFT or other carrier that may hold it. It is the meaning the user can receive through the path they entered.
That distinction matters because Yokefellow is built to make participation understandable before it happens, not mysterious afterward. If a person buys something, earns something, requests something, applies for something, or is granted something through a bucket, the platform should be able to say what they may receive in clear terms. A right is the clearest language for that because it keeps the focus on what the person may actually do, use, hold, access, prove, control, redeem, or carry forward.
A right is also something structured by the offering and its context. It does not exist in the abstract. The offering defines the path, the bucket provides the context, and the configured surface around the carrier helps determine what the right actually is in practice.
This is also why a right should be treated as potentially conditional, limited, or context-specific. A right may be real without being permanent. It may be useful without being unrestricted. It may matter inside one bucket or one app surface without meaning the same thing everywhere else. Yokefellow is stronger when rights are described precisely enough that the user understands the actual scope of what they may receive.
A right on Yokefellow is not only something a person may receive and hold. In some paths, a right may also function as a prerequisite, a gate, a consumable input, or a transformation input for a later offering. That means a right may matter not only at acquisition time, but also later when the holder uses, proves, holds, burns, combines, redeems, or transforms it inside another structured path.
5. What a Right Is Made Of
A right on Yokefellow is not only a category. It is an assembled entitlement.
5.1 Bucket context
A right begins in context. Buckets are the core participation surfaces on Yokefellow, so the bucket often provides the initiative, meaning, and scope that make the right understandable. A ticket-like right tied to one bucket is not automatically the same as a ticket-like right tied to another. A posting right tied to one bucket is not automatically the same as a posting right tied to another. The bucket gives the right its operating environment.
5.2 Offering path
A right is shaped by the offering path that produced it. A right received through purchase is not the same as one received through earned qualification, request, application, or grant, even if the resulting carrier looks similar. The acquisition path changes what the user should expect and how the right should be described.
5.3 Carrier layer
A right is often carried by an NFT. The collection and class provide the carrier layer that gives the right a durable form. This matters because the system needs a stable object that can be held, recognized, transferred where allowed, or consumed where designed.
5.4 Control layer
A right is shaped by the controls attached to the carrier and the path. Transfer rules, burn rules, minting posture, supply caps, per-wallet limits, selection behavior, and metadata controls all help determine what kind of right the user is actually holding.
5.5 Scope layer
A right is shaped by where it belongs. Some rights matter mainly inside the issuing bucket. Some matter inside one or more apps. Some matter inside a tool, a competition, an event, a product flow, or a work relationship. The scope is part of the right’s meaning, not an afterthought.
5.6 Interpretation layer
A right is shaped by metadata and code. Metadata helps describe or parameterize what the right can do. Application code and tool logic are what often turn the right into usable behavior. That is how the same carrier model can support very different rights surfaces without pretending all rights mean the same thing.
The clearest way to think about it is simple: a Yokefellow right is not only issued. It is configured, carried, scoped, and interpreted.
6. Acquisition Paths
Rights do not all enter the user’s hands the same way. The acquisition path matters because it changes user expectations.
6.1 Bought rights
A bought right is received through a priced participation path. The user enters by satisfying the stated economic terms.
This is often the easiest path for users to understand because the entry condition is explicit. But a bought right is not automatically unconditional, permanent, or unrestricted. It only means the acquisition path was purchase rather than qualification or assignment.
6.2 Earned rights
An earned right is received because the user qualified through action, achievement, contribution, completion, or another recognized basis.
This matters because Yokefellow is not only about selling outputs. It is also about preserving value that comes from participation, performance, or contribution.
6.3 Requested rights
A requested right begins when the user asks to enter a path that still depends on later processing or resolution.
This creates an intermediate state between interest and final result. The right may be meaningful, but the user should understand that entering the path is not always the same as the right being fully resolved already.
6.4 Applied-for rights
An application-based right begins when the user enters a selection process rather than an automatic acquisition path.
This matters where eligibility, fit, capacity, or judgment still shape who receives the right.
6.5 Granted rights
A granted right is received through assignment rather than through direct purchase or open qualification.
This matters because some rights are supposed to be given, awarded, delegated, or assigned by an operator or system decision. That does not make the right vague. It changes where the path begins.
These paths matter because a bought right, an earned right, a requested right, an application-based right, and a granted right should not be described as if they were interchangeable.
7. Collections, Classes, and the Right Carrier
A right on Yokefellow is often carried through a collection and a class. That carrier layer matters because rights do not float through the system as abstract promises. They need a durable way to be grouped, issued, held, recognized, transferred where allowed, and consumed where designed. The collection-and-class structure is the layer that gives rights that durable shape.
7.1 Collections
A collection is the grouped carrier surface for related rights. It is the contract-backed grouping that gives the system a stable place to organize outputs that belong together.
Collections matter because the right is often part of a larger family of related entitlements rather than one isolated object. One collection may hold event-related rights. Another may hold operator or posting-related rights. Another may hold digital item or tool-use rights. Another may hold product claims or work-role carriers. The collection groups related carriers together so the system can treat them as part of one recognizable surface instead of a scattered set of unrelated issues.
That grouping matters for more than neat organization. It affects how users understand what they are holding, how operators issue rights coherently, how apps recognize related outputs, and how the platform keeps meaning attached to a recognizable family of entitlements over time. A collection therefore helps stabilize the right environment around the holder, the operator, and the surfaces that need to interpret it.
7.2 Classes
A class is the specific output type inside that grouped context. If the collection is the family, the class is the distinct right-bearing type within that family.
A class is often the clearest carrier-level definition of what sort of right the system is about to issue. A class may represent a specific access right, a specific participation tier, a specific role, a specific type of digital object, a specific product claim, or another defined output type. This is important because users and operators often need a layer more precise than the collection as a whole. The collection may tell them what broad surface they are in. The class tells them what specific kind of carrier they are dealing with.
That means a class is often where the right becomes most legible at the carrier level. It is the place where the platform can distinguish one output type from another even when both belong to the same broader grouped surface.
7.3 Carrier standard: 721 and 1155
The carrier standard matters too. A unique 721-style output behaves differently from an 1155-style repeatable or quantity-based output. That difference can affect how the right is issued, distributed, accumulated, consumed, or recognized in practice.
A 721-style carrier is usually better suited to rights where uniqueness, individual identity, singular holding, or one-by-one significance matters more. An 1155-style carrier is usually better suited to rights that may exist in quantity, repeat across many holders, or need more flexible quantity-based behavior.
This does not mean one standard is inherently more valuable than the other. It means the carrier standard changes how the right behaves operationally. A right tied to a unique one-off credential, named role, or singular item may fit one standard better. A right tied to repeatable access, repeated issue, or quantity-based game or product logic may fit the other better.
7.4 Why the carrier layer matters without replacing the right
The platform should treat the carrier layer as meaningful, but still secondary to the right itself. The collection and class define how the entitlement is carried. They do not replace the user-facing explanation of what the entitlement means.
That distinction is important because users should not be forced to read the carrier structure as if it were the whole point. The collection tells them what grouped surface they are in. The class tells them what specific output type they may receive. The carrier standard shapes how that output behaves. But the right is still the user-facing value: what the person may actually do, use, access, prove, redeem, control, or carry forward.
The clearest way to understand this layer is simple. Collections group related rights. Classes define the specific carrier type. The standard affects how that carrier behaves. None of those layers should be mistaken for the whole meaning of the right, but all of them help make the right durable, legible, and usable inside the system.
8. Carrier Behavior and Control
The tool does not only classify rights. It shapes their behavior directly through configurable carrier controls. That is why Yokefellow should describe transfer, burn, supply, minting, and metadata control as core parts of the right itself rather than as low-level implementation details.
8.1 Transferability
Some rights are transferable. Some are restricted. Some are soulbound.
This matters because transferability changes what kind of entitlement the holder actually has. A transferable right can move between holders. A restricted right can move only under narrower conditions. A soulbound right is meant to remain attached to the holder because its meaning is identity-linked, role-linked, credential-like, or otherwise personal.
Transferability is therefore one of the clearest design axes in the system. It determines whether the right behaves more like a movable asset, a controlled entitlement, or a non-transferable status or qualification.
In practice, Yokefellow exposes this directly through transfer mode. Rights should not be discussed as if all carriers are meant to move the same way.
8.2 Burnability and Consumption
Some rights are held. Some rights are checked. Some rights are consumed.
A right may function as a continuing entitlement that the holder simply keeps. A right may also function as a gate that must be held in order to unlock another action. In other cases, a right may be burned or otherwise consumed in order to redeem, transform, craft, upgrade, convert, or complete another path.
This matters because burnable rights are not only passive things a user owns. They can also be spendable, redeemable, or transformable parts of a larger system.
A right that can be burned should be described differently from a right that is only meant to be held. A right that must merely be held for eligibility should be described differently from a right that is consumed on use. These are not minor implementation details. They are part of the right’s meaning.
In the current Yokefellow tool, this distinction appears directly in offering input rules. A later offering may require NFTs to be held or burned in order to continue. That means some rights function as prerequisites, some function as consumables, and some function as transformation inputs in a larger flow. A right may therefore matter not only because it is held, but because it is one of the ingredients required to unlock a later result.
8.3 Supply and Distribution Limits
A right may be limited by max supply or by max per wallet. These controls matter because they define how widely the right can exist and how concentrated it can become.
A right that is capped globally behaves differently from a right that can be minted indefinitely, and a right that is capped per holder behaves differently from one that can be accumulated by a single wallet. These limits may affect scarcity, fairness, competition structure, access distribution, or operator discipline.
Yokefellow exposes these controls directly because they are part of the meaning of the right, not just part of its storage.
8.4 Minting and Issuance Posture
A right may also be shaped by how issuance is expected to happen. Some rights are effectively instant. Others are approved. Others are manual.
This matters because a user should be able to tell whether the right is meant to issue automatically, depend on approval, or rely on a more operator-directed process.
Yokefellow exposes this directly through mint mode and through offering-side fulfillment options. These two layers should be read together, not separately.
8.5 Metadata Control and Stability
A right may also be shaped by whether metadata can still change and whether the carrier is meant to remain editable or become fixed.
Locking metadata freezes meaning. Leaving metadata editable may preserve flexibility, but it also means the interpretation layer can still evolve. These controls affect what users should assume about the stability of the right over time.
8.6 Holder-Specific Behavior
Some rights are better treated as more personalized than others. A credential-like right, a named contractor role, a specific work assignment, or a one-off competition entitlement may require more individualized interpretation than a broadly repeatable access pass.
Yokefellow exposes this directly through the personalized-per-mint posture. Some rights are not only one class among many identical copies. Some are intended to carry more individualized meaning at issue time.
8.7 Live Collection Controls
The rights model does not stop once a carrier exists. Live collection controls matter too.
Controls such as setting max supply, locking minting, locking metadata, locking or unlocking transfers, and syncing ownership all affect what can still change after the right is already in circulation. Those controls matter because the stability of a right is partly a function of what remains mutable after issuance.
9. Selection and Fulfillment
The same broad right can resolve through very different system paths.
9.1 Selection
An offering may resolve into a fixed output, a chosen output, or a random weighted output.
That means the user may know the exact right in advance, choose among defined rights, or receive one result from a governed pool. This matters because certainty of result is part of the participation path. A direct ticket right and a weighted loot-like right should not be described to users in the same way just because both are carried by NFTs.
Yokefellow reflects this through selection mode and through output-level settings such as weight, stock limit, and presentation overrides. That means one offering can point to several possible results with different odds, limits, and presentation logic.
9.2 Fulfillment
An offering may resolve through immediate issuance, pending request state, manual review, or delayed resolution.
This matters because the timing and certainty of the right are part of the user experience. A right that issues immediately is different from a right that depends on later review or later processing.
Yokefellow should therefore describe rights together with their fulfillment posture. A user should be able to tell whether the result is immediate, pending, review-dependent, or later-resolved.
Yokefellow reflects this through fulfillment mode and related publishing controls. That makes fulfillment part of the right’s visible design, not only an internal workflow concern.
10. Tool Logic and the Option Families That Shape Rights
The clearest way to explain Yokefellow rights is not to hide the tool logic. The system should say plainly that rights are shaped by actual configurable option families.
At the class layer, Yokefellow shapes a right through fields such as transfer mode, max supply, max per wallet, mint mode, personalized per mint, status, metadata JSON, and class capabilities. These are not cosmetic settings. They help determine what kind of right the user is actually holding.
Transfer mode can be transferable, restricted, or soulbound. Max supply controls how many carriers may exist. Max per wallet controls how concentrated the carrier may become. Mint mode changes how issuance is expected to happen. Personalized per mint matters when a right is more individualized. Status determines whether the class is active as a live issuing surface. Metadata JSON provides a direct configuration layer for app-side and surface-side interpretation.
At the capability layer, scope types include organizational scope, bucket scope, team scope, event scope, season scope, and custom scope. This matters because the same right can be recognized at different levels. Some rights are broad organizational entitlements. Some are bucket-bound. Some are team, event, or season specific. Some need a custom scope.
At the offering layer, Yokefellow shapes rights through mode, price rule, selection mode, fulfillment mode, publishing status and limits, output pool configuration, and eligibility or application configuration.
Mode can be purchase, earned, request, application, or grant. Price rule can be free, fixed YES, or dynamic USD. The dynamic option is the 24-hour EWMA model. Fixed YES can be entered as human YES or raw YES. The dynamic pricing model may also include operational guardrails such as lookback window, half-life, minimum trades, and minimum YES volume. Those settings do not change the category of the right, but they do change how the priced path is governed.
Selection mode can be fixed, choice, or random. Fulfillment mode can be auto mint, pending request, manual review, or delayed resolution. The publishing layer can also carry status, active state, sort order, max supply, and max per wallet. These matter because the right is not only defined by concept. It is also defined by how it is published, limited, and surfaced.
At the output layer, Yokefellow can shape a right through active state, sort order, weight, stock limit, label override, image override, and per-output metadata. These options matter because one offering may resolve into several possible outputs that do not all behave identically. Weight matters in random resolution. Stock limit matters because one output may be capped more tightly than the broader class it points to. Overrides matter because one class may be presented differently inside different offering contexts.
At the input-rule layer, crafting and transformation logic also become part of the rights model. Rules such as hold requirements and burn requirements matter because they determine whether a right is merely carried, used as a prerequisite, or consumed in order to complete another path. That means some rights on Yokefellow are not only things the holder keeps. They may also be gates, consumables, crafting inputs, or redeemable inputs.
In the current tool, crafting and transformation logic are not hypothetical. An offering may carry input rules that require specific NFT classes in specific quantities before the path can continue. Those input rules currently distinguish between hold requirements and burn requirements. A hold requirement means the holder must possess the required NFT inputs but does not consume them. A burn requirement means the required NFT inputs are actually consumed as part of the path. This means some rights on Yokefellow are not only final results. They may also function as ingredients, prerequisites, or transformation inputs for later offerings.
These input-driven paths can still resolve through the normal output-selection layer, which means a crafted result may still be fixed, chosen from a valid set, or resolved from a weighted configured output pool.
This full option map matters because the rights model should be understandable not only in theory but also in operation. A right on Yokefellow is not only described in prose. It is configured through the actual option families the tool exposes.
11. Scope and Where Rights Apply
A right on Yokefellow is easier to understand when its scope is stated plainly. Scope answers a basic question the user should never have to guess at: where does this right actually matter.
That question matters because a right can be real and still be narrow. It can be valuable and still be tied to one bucket, one app, one tool, one event, one product flow, one role, or some defined combination of those surfaces. A right becomes harder to understand when the holder knows what they received in name, but not where that right has force in practice.
This is why scope should be treated as part of the right itself. A right is not fully described until the user can tell whether it applies locally, broadly, temporarily, continuously, or across more than one surface at once.
11.1 Bucket scope
Some rights are tied closely to a bucket. They matter because of the bucket that issued them and the initiative that bucket represents.
A bucket-scoped right may control access to that bucket’s activity, preserve a role inside that bucket, carry status in relation to that bucket, or affect what the holder may do on that bucket’s surface. In these cases, the right should be read together with the bucket context, because the issuing bucket is part of what gives the right its meaning.
On the main Yokefellow surface, a right may also connect to a bucket through bucket-specific bindings. Those bindings are part of how the main app recognizes that a held NFT or related right should matter to a particular bucket surface.
That distinction is important. A bucket binding is not the whole rights model. It is one main-app way of attaching meaning or force to a bucket surface. It helps connect the right to the bucket, but the right may still carry broader meaning elsewhere depending on how other surfaces interpret it.
11.2 App scope
Some rights matter inside an app rather than only on the bucket page. They may unlock actions, features, roles, tools, goods, spaces, competitions, or digital behaviors inside one app or across multiple apps.
This matters because Yokefellow is not trying to confine all meaning to the main bucket page. A right may begin in a bucket, but its practical use may appear inside an app experience that gives the holder something to do, unlock, access, control, or carry forward there.
A right may therefore be bucket-issued and app-used at the same time. That does not make it unclear. It means the scope needs to be named directly so the holder understands where the right becomes active.
11.3 Tool scope
Some rights matter inside tools. A right may grant access to use a tool, to use a tool at a certain level, to create through a tool, or to perform a role within a tool surface.
This matters because tool rights are not always simple access passes. A right may permit use, higher-tier use, creation rights, operational rights, moderation rights, or another scoped behavior inside the tool itself. In those cases, the user should be able to tell not only that the right relates to the tool, but what kind of use or authority the tool recognizes.
11.4 Product scope
Some rights matter in relation to produced goods. A right may entitle the holder to claim, redeem, receive, configure, or otherwise participate in a product or output tied back to the bucket and offering.
A product-scoped right should therefore be read in relation to the thing it may help the holder receive or configure. In some cases, the right may function like a claim. In other cases, it may function more like eligibility, redemption, access to configuration, or participation in a later fulfillment step.
This matters because product-related rights are often misunderstood when users treat the carrier as the product itself. The clearer model is simpler: the right may relate to a product flow, but the scope of that relationship still has to be stated.
11.5 Event and participation scope
Some rights are about attending, entering, participating, competing, contending, or otherwise taking part in a live or staged activity.
This kind of scope matters because a right tied to participation is not always the same as a right tied to observation or ownership. The holder may be receiving the right to enter, the right to compete, the right to take part in a process, or the right to occupy some defined place within a time-bound activity.
That means event and participation rights should be described with their actual role in the activity. A right to attend is not the same as a right to compete. A right to compete is not the same as a right to hold a role within the event. Scope keeps those differences legible.
11.6 Work and role scope
Some rights may grant the ability to perform a job, hold an operator role, or act in an independent-contractor capacity under a defined surface.
These rights should be read as scoped authorities or scoped roles, not as vague platform ownership. A user may be allowed to act, operate, manage, produce, post, review, build, fulfill, or otherwise work within a defined context because the right recognizes that role there.
That makes work and role scope especially important to state clearly. If the right carries authority, the holder should know where that authority starts, where it stops, and what surface recognizes it.
11.7 Multi-surface scope
Some rights may carry meaning across more than one surface at once. A right may start from a bucket, remain visible in the main app, unlock behavior in an app, gate use in a tool, and later connect to product or participation flows elsewhere.
That does not make the right vague. It makes scope description more important.
A multi-surface right should therefore be described as multi-surface on purpose, not left to implication. The holder should be able to tell whether the right begins in one place and matters in another, whether it is recognized in several places at once, and whether those surfaces all grant the same force or only different parts of the same broader entitlement.
11.8 Why scope has to be stated directly
The safest rule is simple: a right is not fully explained until its scope is stated directly.
Users should not have to infer whether a right is local to a bucket, active across apps, relevant only inside a tool, tied to a product claim, limited to event participation, or recognized as a work or authority role. Scope is part of the right’s actual meaning. The clearer that scope is described, the easier the right is to understand, trust, and use correctly.
12. Main-App Bindings, Broader Permissions, and Authority
Yokefellow should distinguish clearly between main-app bucket bindings and the broader rights logic that can exist across other surfaces.
A bucket binding is a main-app relationship. It is the way the Yokefellow surface recognizes that a held NFT or related right should matter to a specific bucket. That relationship may attach meaning, authority, or usable force to the bucket surface, but it should still be understood as a bucket-layer connection inside the main app.
That is only one layer of the rights model.
A right may also carry authority, capability, or usable force in apps, tools, and other interpreted surfaces that are not fully explained by a main-app bucket binding alone. A right may therefore matter on the bucket page, inside an app, inside a tool, or across several surfaces at once, depending on what permissions, capabilities, metadata, and code recognize it.
This distinction matters because some rights are mainly benefits while others are active authority-bearing entitlements. A right may function as access, but it may also function as scoped authority. It may let a holder post, publish, name, review, manage, create, process, or operate within a defined surface.
On the main app, this becomes concrete through bucket permission families such as posting, managing offerings, managing classes, processing issuance, processing requests, managing permissions, or managing bucket bindings. Beyond the main app, broader capability-driven rights may appear through app-side keys and logic that interpret the carrier differently.
The practical rule is simple. Bucket bindings belong to the main-app bucket layer. Broader rights behavior may also be recognized through permissions, capabilities, metadata, and application logic in other surfaces. The holder should not have to guess which is doing the work. The offering and surrounding structure should make that clear.
13. Metadata and Code Extension
Metadata and code are not side notes in Yokefellow. They are part of how the right becomes usable.
Metadata can help define what the right is for, how it should be displayed, what state it is in, what limits apply, or what external or app-side meaning it carries. Code and tool logic then interpret that information and turn it into behavior.
That is how a right can extend into:
bucket surfaces on the main app
one or more apps
tool usage
digital items and in-app objects
product claims and redemption flows
access and attendance checks
competition or participation gating
contractor or role-based utility
evolving states such as redeemed, consumed, upgraded, equipped, placed, or depleted
This is why the NFT carrier alone is never enough explanation. The right becomes fully legible only when the carrier, metadata, and system logic are read together.
This is also why Yokefellow rights are so flexible. The system is not limited to one kind of output just because the carrier layer is familiar. What the right actually does depends on how the carrier is interpreted and what surfaces recognize it.
14. Types of Rights
The construction model explains how a right is built. The categories below explain what kind of value the user is receiving. These categories should help users and operators describe rights more clearly, not flatten them into one generic class.
14.1 Access rights
An access right is the right to enter, reach, or unlock something. That something may be an event, a space, a channel, a feature, a release, a program, or another controlled surface. The key point is that the right is about entry, not automatic ownership of the thing being entered.
14.2 Participation rights
A participation right is the right to take part in something rather than merely observe it. It may allow entry into a competition, inclusion in a program, a place in a season, or another active role inside a defined process.
14.3 Reward and proof rights
A reward or proof right preserves the fact that something was earned, completed, achieved, or contributed. Its value may lie in recognition, later use, visible standing, or proof-bearing record rather than in simple access alone.
14.4 Status rights
A status right is the right to hold a visible position, affiliation, rank, or recognized identity inside a surface. It matters because the user is not only receiving utility. They are receiving a recognized standing.
14.5 Decor and display rights
A decor or display right is the right to place, show, use, or present something in a defined context. This may affect how a user, space, item, or identity appears where that display is supported.
14.6 Control and authority rights
A control or authority right is a right tied to a more specific power or responsibility. It may include posting authority, naming authority, role authority, operator authority, management authority, or another defined control within a scoped context.
14.7 Product and redemption rights
A product or redemption right is the right to claim, receive, redeem, configure, or otherwise participate in a product or output flow. It matters because the right is tied to a deliverable or redeemable result, not only to presence inside the system.
14.8 Tool and use rights
A tool or use right is the right to access, use, create through, or operate within a tool surface. This can include simple access, higher-level use, creation ability, or scoped operating ability inside that tool.
14.9 Work and role rights
A work or role right is the right to perform a defined job, hold a role, or act in a recognized capacity under the stated structure. These rights should be read as scoped roles or scoped working authority, not as vague platform ownership.
These categories are useful because they help describe the user-facing result directly. But they should still be read together with the path, carrier behavior, scope, and limits that define how the right actually works in practice.
14.10 Transformation and crafting rights
Some rights function as transformation inputs rather than only as end-state entitlements. They may need to be held, checked, combined, or burned in order to unlock a later result. This matters because Yokefellow rights are not only things a user receives and keeps. In some paths, they are also ingredients in later structured participation. A transformation or crafting right should therefore be described not only by what it grants on its own, but also by what later paths it may unlock, shape, or help produce.
15. Constraints, Expirations, Limits, and Conditions
A right on Yokefellow is defined not only by what it allows, but also by the boundaries attached to it. Those boundaries are not side notes. They are part of the right itself.
This matters because a right can be real, useful, and valuable while still being narrow, conditional, temporary, or context-bound. A right does not become weaker just because it has limits. In many cases, the limits are what make the right understandable and trustworthy. A right tied to one bucket, one event, one season, one product flow, one role, or one approval path is often clearer and more honest than a right described in broad language that hides those boundaries until later.
That is why Yokefellow should treat constraints, expirations, limits, and conditions as first-class parts of rights design. They should be stated clearly before participation, not discovered after the fact.
15.1 Constraints are part of the right
A right should be read together with its constraints. If a right grants access, the user still needs to know whether that access is broad or narrow, one-time or recurring, local or cross-surface, automatic or review-dependent. If a right grants a power or privilege, the user still needs to know where that power applies, what surface recognizes it, and what boundaries limit its use.
A right without its constraints is only half-described. That is one of the main ways platforms create confusion: they describe the attractive part of the right and leave the user to infer the actual boundaries on their own. Yokefellow should do the opposite. The boundaries should be part of the main explanation.
15.2 Time limits and expiration
Some rights last indefinitely within their intended context. Others expire at a defined time, after a defined event, after a season ends, after a use window closes, or after another stated condition is reached.
Expiration is therefore not a sign that the right is weak or fake. It is often the clearest way to match the right to the initiative it belongs to. A right tied to one event, one competition window, one season, one release period, or one temporary role may be better if it ends when that context ends.
The important thing is that duration should be stated directly. Users should not have to assume whether a right is permanent, temporary, renewable, or one-time.
15.3 Usage limits
Some rights are limited by usage count, redemption count, quantity, or another practical limit on how often they may be exercised.
A right may allow one entry, one claim, one redemption, one posting slot, one naming slot, one tool action, one participation window, or another bounded result. That does not make the right less real. It makes the right more specific.
Usage limits matter because the holder should be able to tell whether the right is continuous or exhaustible. A right that can be exercised once behaves differently from a right that can be exercised repeatedly, and a right that is consumed on use behaves differently from one that remains after use.
15.4 Eligibility limits
Some rights depend on eligibility conditions. A user may need to hold a prerequisite, meet a qualification standard, satisfy a role condition, belong to a recognized group, or otherwise match the conditions the offering or surface requires.
Eligibility limits matter because not every right is meant for every participant. Some rights are intended to be open. Others are intentionally restricted to people who satisfy defined conditions. The right is easier to trust when that eligibility standard is visible up front rather than quietly enforced later.
15.5 Review-dependent and approval-dependent conditions
Some rights are not fully resolved at the moment the user enters the path. They may still depend on request processing, application review, operator judgment, queue handling, or later fulfillment.
That means a right may be meaningful without being immediately final. A user may have entered the path correctly and still not yet hold the fully resolved result. This is especially important in request-based, application-based, manual-review, or delayed-resolution flows.
Yokefellow should therefore describe clearly whether the right is automatic, pending, review-dependent, or later-resolved. A review-dependent right is not the same as an immediately issued right, and users should not be pushed into treating those two cases as interchangeable.
15.6 Scope limits
A right may also be limited by where it applies. It may be bucket-scoped, app-scoped, tool-scoped, product-scoped, event-scoped, role-scoped, or otherwise tied to one or more defined surfaces.
Scope limits matter because a right can be meaningful in one place without carrying the same force everywhere else. A right that matters inside one bucket should not be read as if it automatically carries platform-wide meaning. A right that unlocks one app surface should not be read as if it grants the same result across every other surface.
This is why scope should be treated as a core condition, not a secondary note. Where the right matters is part of what the right is.
15.7 Transfer, burn, and carrier-behavior limits
Some rights are transferable. Some are restricted. Some are soulbound. Some are burnable. Some are hold-gated. Some are consumable. Some remain usable only while held, while others are designed to be spent in order to unlock another path.
These behavioral limits matter because they change what the holder can actually do with the right after receiving it. A transferable right can circulate. A restricted right can move only under tighter rules. A soulbound right is intended to remain attached to the holder. A burnable right may be redeemed, transformed, crafted, or consumed.
Some rights may also function as prerequisites inside later offering logic. A holder may need to possess a required right, or may need to burn that right, in order to unlock a later result. That means carrier behavior is not only technical detail. It is part of the actual limit structure and practical meaning of the right.
15.8 Operator-managed and mutable conditions
Some rights are fixed once issued. Others remain partly shaped by ongoing operator or system controls. Metadata may remain editable. Minting may remain open. Supply may still change until a cap is locked. Transfer settings may still be mutable. Fulfillment may still depend on later action.
These conditions matter because the user should understand what parts of the right are stable already and what parts may still be subject to later management. A right can still be real while some surrounding controls remain operator-managed, but that should be stated clearly rather than hidden behind permanent-sounding language.
15.9 Why clear boundaries build trust
A right is easier to trust when the user can see the actual limits up front. It becomes harder to trust when the platform uses broad, permanent-sounding, or unrestricted language for something that is actually narrow, temporary, review-dependent, scope-limited, or heavily conditioned.
The practical rule is simple: say the boundaries as clearly as the benefit.
A right on Yokefellow should not be explained only by what it allows. It should also be explained by how long it lasts, where it applies, what conditions shape it, what behavior governs it, and what still has to happen before it is fully usable. That is what makes the right legible before participation happens, which is one of the core standards the platform should aim for.
16. What a Right Does Not Guarantee
A right on Yokefellow does not automatically guarantee:
ownership in Yokefellow itself
profit or financial return
permanence
unrestricted use
platform-wide force
immediate approval where review still applies
broader authority than the offering, bucket, and configured surfaces actually grant
The strongest rule is the simplest one: a right does not guarantee more than the real structure says it does.
This matters because Yokefellow is stronger when it avoids vague implication. A right may still be meaningful, useful, valuable, or important without being expanded into platform ownership, unrestricted control, or automatic financial claim.
17. Best Practices for Creators and Operators
Rights are easier to trust when they are described as plainly as they are designed. The creator or operator’s job is not only to make the right attractive. It is to make the right legible before participation begins and usable afterward without confusion.
A right becomes harder to trust when the user has to infer the real meaning from labels, marketing tone, or scattered surfaces. It becomes easier to trust when the user can tell what the right is, how it is obtained, where it matters, how it behaves, what limits shape it, and what it does not promise. That is the standard creators and operators should aim for.
17.1 Describe the right before the carrier
State what the user may actually do, access, use, prove, redeem, control, or carry forward before focusing on the NFT itself.
The carrier matters, but it should not be the first or only explanation. Users should not have to translate “you receive this token” into “here is what this actually lets you do.” The plain-language meaning should come first. The carrier should then be explained as the way that right is held and recognized.
17.2 Match the language to the real scope
Describe the right at the same level of scope it actually has.
If the right is bucket-specific, app-specific, tool-specific, role-specific, temporary, or conditional, say so directly. If it applies only inside one event, one program, one product flow, one work surface, or one defined context, that should be clear from the description.
Broad language should not be used for narrow rights, and permanent-sounding language should not be used for temporary ones. A right is easier to trust when the wording matches the real scope exactly.
17.3 Make the acquisition path explicit
Users should be able to tell whether the right is bought, earned, requested, applied for, or granted.
The acquisition path shapes expectations and should never be left implied. A purchased right should not be written like a granted right. A request-based right should not be written as if entry alone guarantees final resolution. An application-based right should not be written as if it were simple open access.
The user should be able to tell not only what the right is, but how that right is supposed to enter their hands.
17.4 Make the behavior explicit
Users should be able to tell whether the right is transferable, restricted, soulbound, burnable, consumable, hold-gated, capped, immediate, review-dependent, or later-resolved.
These are not secondary details. They are part of the right’s actual meaning. A right that can be transferred is different from one that must remain attached to the holder. A right that can be burned is different from one that must only be held. A right that issues immediately is different from one that depends on later review or delayed fulfillment.
Users should also be able to tell whether the right is only an end-state entitlement or whether it may later function as a prerequisite, input, or ingredient in another path. Behavior should therefore be described as part of the main explanation, not hidden in fine print.
17.5 Make the operating surface explicit
Users should be able to tell where the right actually matters: on the main app, inside one or more apps, inside a tool, inside a product flow, inside an event, or inside a work or authority context.
This matters because rights on Yokefellow are often multi-surface in meaning. A right may begin in a bucket, become active in an app, control access to a tool, or later matter in a product or participation flow. If the surface where the right has force is not stated clearly, the user is left with only partial understanding.
The rule is simple: say where the right works.
17.6 Do not imply more than the structure grants
Do not use language that suggests platform ownership, guaranteed return, unrestricted control, permanence, or broader authority unless the system truly and lawfully grants exactly that.
This is one of the most important rules in the whole paper. Rights are easier to trust when they are described for what they are, not inflated into something larger because broader language sounds stronger. A right may still be meaningful, valuable, and compelling without implying ownership in Yokefellow, automatic financial upside, platform-wide power, or unlimited duration.
The description should not promise more than the actual structure supports.
17.7 Issue only rights the surface can actually support
A right should only be issued if the bucket, app, tool, product flow, or operating surface can actually carry it cleanly.
A right that sounds attractive but cannot be fulfilled weakens trust in the whole system. If the right depends on later redemption, operator action, product delivery, review, posting authority, or continued recognition in an app or tool, the issuing surface should already be prepared to support that result in practice.
Good rights design is not only about imagination. It is also about operational honesty.
17.8 Keep the context visible where it matters
If the right depends on the issuing bucket, the app surface, the tool surface, or another defined context, keep that context visible.
Context is often part of the right’s actual meaning. A naming right tied to one bucket is not the same as a naming right tied to another. A posting right inside one surface is not automatically a posting right everywhere else. A product right tied to one flow is not automatically broad product ownership. The issuing context helps define the right, and the user should be able to see that clearly.
17.9 The practical standard
The practical standard is simple: describe the right as if the user will rely on the description later.
A strong rights description should let the user answer these questions before participating:
What is this right?
How do I receive it?
Where does it matter?
How does it behave?
What limits or conditions shape it?
What should I not assume from it?
If the description cannot answer those questions cleanly, the right is not yet described well enough.
18. User Reading Guide
A user on Yokefellow should not have to reconstruct the meaning of a right by piecing together scattered surfaces on their own. The main user-reading surface should be the bucket’s policy page.
The bucket policy page should be the place where a user gains a practical understanding of what the bucket is offering, what classes or rights can be received through it, how those paths work, what behavior those rights have, where they matter, and what limits or conditions apply. In other words, the policy page should be the canonical reading surface for users.
That matters because offerings are the paths users enter and classes are part of what users may actually receive. If the user has to guess how the offering and class fit together, the system is not being explained clearly enough. The user should be able to read one stable surface and understand the structure before participating.
The safest user rule is simple: read the bucket policy page first.
That policy surface should explain, in a user-readable way:
what the bucket is for
what offerings exist in the bucket
what classes or rights those offerings can resolve into
whether those rights are immediate, pending, review-based, or later-resolved
whether those rights are transferable, restricted, soulbound, hold-gated, burnable, capped, temporary, or otherwise conditioned
where those rights are meant to matter
what the user should not assume beyond the actual structure
A strong policy page should therefore do more than list offerings. It should connect the offering path to the possible classes or rights, explain how those outcomes behave, and make clear what kind of result the user is actually entering. The point is not only to show that something exists. The point is to make the structure readable enough that the user can make an informed decision before acting.
Users should still be able to inspect the offering and related surfaces directly, but the policy page should be the place where the structure is made readable before participation happens. The offering surface may show the live path. The class or right surface may show the specific carrier. But the policy page should be the place where those parts are tied together in plain language.
The strongest user rule is simple: start with the bucket policy page, then read the specific offering and class details it identifies. That is how a Yokefellow right becomes understandable before participation happens.
19. Closing Frame
A right on Yokefellow should be understandable before participation happens.
That is the standard the platform should aim for. The point is not only to issue tokens. The point is to issue legible, configurable, enforceable, or recognizably scoped entitlements that people can actually understand and use.
The offering explains the path. The NFT often carries the entitlement. The controls shape its behavior. The context tells the user where it matters. Main-app bindings may connect it to bucket surfaces. Permissions, capabilities, metadata, and code may extend it into other usable surfaces. Read together, those layers explain what the user may actually receive — no less, and no more.