Yokefellow - How Yokefellow Works
Mechanics
The operating model: buckets, offerings, rights, mechanics, balances, queues, issuance, activity, and indexing.
1. System Overview
Yokefellow is a working system built from a small set of connected objects and flows. Buckets provide the base participation surface. Offerings define how participation is made available. Rights are what offerings can grant, carry, or prove. YES supports economic activity across the system where a native participation layer is needed. Operators manage configured behavior and fulfillment where the system calls for it. Activity, receipts, and indexing make the results visible afterward. This paper explains how those parts relate and behave. It does not restate the mission, document the API, map every contract, or walk through operator screens.
At the system level, Yokefellow is designed to make participation structured instead of vague. A bucket does not only show that something exists. It defines a surface where terms, offerings, rights, and operator-controlled behavior can be attached to the same initiative. That structure matters because support, access, proof, and fulfillment are otherwise easy to scatter across separate tools and separate records. In Yokefellow, those parts are meant to stay legible as parts of one system, even when an initiative takes a very different form from the next one.
The rest of this paper moves from objects to behavior. It first defines the core system objects, then explains bucket mechanics, balance semantics, offering modes, pricing, output selection, fulfillment, issuance, permissions, queue flows, and visible activity. The goal is precision without overload. A reader should finish this paper understanding how Yokefellow behaves as a system, where the major distinctions live, and why those distinctions matter for participants, operators, and technical partners.
2. Core System Objects
Yokefellow works through a small set of recurring system objects. These objects are the nouns the rest of the paper depends on
2.1 Bucket
A bucket is the core programmable funding and participation surface in Yokefellow. It is the object that holds the structure of an initiative: balances, mechanic behavior, offerings, rights surfaces, and operator-controlled logic. A bucket is not just a page, wallet, treasury, or campaign. Those may all be visible around it, but the bucket is the system object that ties them together.
2.2 Offering
An offering is the structured way a bucket makes participation available. It can define a purchase path, an earned path, a request path, an application path, or a grant path. The important distinction is that an offering is not automatically a sale, not automatically a mint, and not automatically a promise. It is the system object that defines how a participant may enter a structured path through the bucket.
2.3 Right
A right is the access, participation ability, status, privilege, permission, or utility a participant may receive through an offering. In the Mechanics paper, the right matters as a system object because it is the user-value layer the platform is trying to structure. A right may later be described in more user-facing detail elsewhere, but mechanically it is what the offering is trying to grant, carry, or prove.
2.4 Operator
An operator is the party responsible for configuring, managing, or fulfilling bucket actions and related flows. Depending on the bucket and offering design, the operator may define terms, manage issuance, review requests, resolve delayed outcomes, or attach the controls that make the bucket usable. An operator is not automatically the platform itself and is not automatically the participant. It is a distinct system role with responsibility for the bucket’s configured behavior.
2.5 Participant
A participant is the person interacting with a bucket or offering. Participants engage with the system by entering offerings, receiving rights, redeeming outputs, or otherwise taking part in the bucket’s participation surface. The term matters because Yokefellow is broader than a simple buyer-seller model. A participant may purchase, earn, request, apply, or receive a grant depending on how the bucket is configured.
2.6 Collection
A collection is a grouped contract-backed container for outputs or rights carriers. It is the system object that groups related NFT outputs or other issuance units under one contract-backed context. A collection is broader than any single output and narrower than the bucket as a whole. It exists so outputs can be organized at a level above the individual class.
2.7 Class
A class is a defined output type inside a collection. Where the collection groups related outputs, the class defines one specific kind of output within that grouped context. Classes matter mechanically because output selection, fulfillment, and issuance often resolve at the class level rather than at the bucket level in the abstract.
2.8 Issuance
Issuance is the broader process through which an offering resolves into an output, a right, or an NFT-backed carrier of that right. Minting may happen inside issuance, but issuance is the larger system concept. It includes the path from structured participation to resolved output, whether that path is automatic, queued, reviewed, or delayed.
2.9 Queue
A queue is the system or operator-managed flow that processes issuance or request outcomes. It exists because not every result is immediate and not every fulfillment path is automatic. Queues make delayed, reviewed, or operator-managed work visible as part of the system instead of leaving those outcomes to vague off-platform handling.
2.10 Binding
A binding is the object that links a right, NFT, permission, or control relationship to a bucket or other target context. Bindings matter because Yokefellow does not treat rights and controls as floating abstractions. A binding attaches them to the system object where they are meant to have meaning. That is how permission and control relationships stay anchored instead of becoming ambiguous.
2.11 Mechanic
A mechanic is the operating behavior of a bucket. It describes how a bucket behaves structurally, including how value and participation move through it.
3. Bucket Types and Mechanics
A mechanic describes how a bucket behaves operationally. The current mechanic set is Splash, Leaky, and Manual. The point of having multiple mechanics is not complexity for its own sake. It is correctness. Different initiatives need different participation and value-movement behavior, and the bucket mechanic is where that behavior is chosen.
3.1 Splash
A splash bucket is a goal-based bucket. Its core behavior is target completion. The bucket is configured to raise toward a defined objective, and that cycle stays open until the target is met or the stated close condition is reached. As participation comes in, progress moves toward a visible finish line. When the goal is met, the bucket no longer behaves like an open raise. It moves into a later closeout posture where redemption, proof posting, reconciliation, and any next-round handling can be organized from a completed state.
Splash fits best when an initiative has a meaningful done moment: an event budget, a discrete buildout milestone, a specific purchase, or a launch window with a clear completion threshold. For operators, the responsibility is to make the target and closeout rules explicit. That includes the goal itself, what counts as completion, redemption rules and window, proof plan, dispute posture, and any caps, deadlines, or eligibility limits. Splash makes completion legible, but only when the finish line is defined tightly enough for participants to understand what they are helping bring about.
3.2 Leaky
A leaky bucket is a time-based bucket. Its core behavior is paced throughput rather than one clean completion moment. The bucket ticks on a schedule, and on each tick it sells a defined percentage or amount of its YES balance into the shared YES/USDC market. The leak rate does not have to remain flat forever. It can be ramped, staggered, or otherwise governed by stated pacing rules, as long as those rules are explicit.
Leaky fits best when the system should behave as an ongoing program rather than a one-time raise. It is suited to recurring initiatives, always-on support models, long-running seasons, and other cases where controlled throughput matters more than a single finish line. For operators, the main responsibility is to define the pacing rules clearly: tick schedule, stagger policy if used, leak rate, ramp policy, and pause or close behavior. Leaky changes how value moves, but it does not remove accountability. Proof, reconciliation, and closeout expectations still have to exist even when the bucket is designed to run as an ongoing flow.
3.3 Manual
A manual bucket is the operator-directed behavior family. Its core behavior is flexibility rather than automatic pacing or automatic goal closure. The system still provides the bucket structure, but timing and many outcome transitions depend on explicit operator action instead of a built-in leak schedule or a built-in target-completion loop.
Manual fits best when the initiative needs discretion more than automation. It is useful when timing is irregular, when conversion or distribution should not happen on a fixed schedule, or when the operator needs tighter judgment around when value moves and when an outcome is ready to advance. The tradeoff is that manual places more responsibility on the operator. The system provides the structure, but the operator carries more of the pacing discipline and execution timing.
4. Balances and Credit Semantics
Yokefellow uses distinct balance states because not all value inside the system is equally free to move. Some value has only been deposited. Some is still available for use. Some is reserved because it has already been committed to an action. Some is spent because it has already been consumed by participation or settled into an outcome. These distinctions matter because the platform supports both public initiative buckets and account-side market activity, and those two contexts need clear accounting instead of one vague “balance” number. At the contract layer, bucket balance truth lives in the vault as free and reserved balances. At the mechanics level, these states explain how value should be understood as it moves through participation and settlement.
4.1 Deposited
Deposited value is value that has entered the relevant bucket or account surface but has not yet been fully consumed. In initiative buckets, deposits create bucket-scoped participation balances, often described as Bucket Credits. Those credits belong to that bucket only. They are not a free-floating platform currency, and they are not automatically tied to one specific offering path until the participant actually uses them inside that bucket. Depositing is therefore the entry into the accounting rail, not the end of the participation flow.
4.2 Available
Available value is the portion of deposited value that is still free to be used. In a bucket context, it is the part of the participation balance that has not yet been committed to an offering action, a reservation, or another system action. In an account context, it is the part of the balance that is not currently tied up by an open market commitment. Available matters because it answers the practical question: what can still be used right now without conflicting with something already committed. This is why the platform cannot treat all deposited value as automatically available.
4.3 Reserved
Reserved value is value that is no longer freely available because it has already been committed to a pending action. The clearest example appears in the account context: value can be reserved so a user cannot place maker-side market activity and then move those same assets away before the commitment resolves. Reserved is therefore the state that protects the system from double-use. Value in this state still belongs to the relevant account or bucket context, but it is temporarily spoken for.
Reserved also matters conceptually inside initiative flows. A system that supports participation, requests, and fulfillment needs a way to distinguish “still free” from “already committed.” Without a reserved state, the accounting becomes easy to misread and easy to abuse. The purpose of reservation is to make commitment visible before final settlement occurs.
4.4 Spent
Spent value is value that has already been consumed by the system’s participation or settlement flow. In an initiative bucket, the clearest example is when a participant uses Bucket Credits on a specific offering path. At that point, the credits are no longer just deposited or available. They have been used to enter that path, and that path may resolve into a request, an issued output, or another definite outcome depending on the offering design. In other words, spent marks the point where the accounting rail has turned into a committed or resolved result.
Spent also matters at closeout. Reconciliation is supposed to answer what happened, what was delivered, what was redeemed, and what was spent. That means “spent” is not just a generic subtraction. It is the state that shows value has actually moved through the loop into a committed or completed result.
4.5 Deposit Behavior
Not every bucket treats deposited value the same way after entry. In the current system, a bucket may behave as a credit-style participation surface or as a capture-on-deposit surface.
In a credit-style bucket, deposited value becomes usable participation credit that can remain available until the participant commits it to a later action.
In a capture-on-deposit surface, the deposit is treated more like immediate commitment than stored participation credit. That distinction matters because the same deposit event can lead to different participation behavior depending on how the bucket is configured.
This is one of the reasons Yokefellow separates deposited, available, reserved, and spent states instead of treating every deposit as if it behaved identically afterward.
5. Onchain and Offchain Roles
Yokefellow works across both onchain and offchain layers because the system is trying to do more than publish static records. It needs contracts that can hold and enforce critical value-bearing actions, and it also needs platform surfaces that can coordinate offerings, operator actions, requests, receipts, and visible history in ways users can actually follow. The point is not to blur those layers together. The point is to keep their jobs distinct enough that the system stays legible.
5.1 What lives onchain
The onchain layer is where the hardest system guarantees belong. It is where token movement, settlement-critical actions, and contract-backed output relationships are enforced. When the system needs something to be independently checkable, durable, and not dependent on one platform database behaving correctly, that responsibility belongs onchain. In Yokefellow terms, this usually includes the contract-backed parts of bucket value movement, market-linked activity, and NFT-linked output or rights carriers.
5.2 What lives offchain
The offchain layer coordinates everything that needs structure, readability, and operational handling without pretending every meaningful action has to be a contract event. Offerings, requests, review states, queue handling, posted proof, receipts, and operator-managed fulfillment all need a platform layer that can organize them cleanly. Offchain is also where the system turns raw participation into usable surfaces people can inspect, compare, and act on. Without that layer, the platform would have records but not much usability.
5.3 Where the indexer fits
The indexer sits between raw onchain activity and the readable system history the platform presents. Its job is not to replace the chain and not to invent its own truth. Its job is to ingest contract activity, normalize it, and make it legible as activity, receipts, balances, and other system-facing records. That is why indexing matters mechanically. A participant or operator should not have to read raw chain events to understand what happened. The indexer turns those events into system history that can be surfaced cleanly without pretending the platform invented the underlying action.
5.4 What operators still own
Not every meaningful part of the system is contract-enforced. Operators still own the human parts that cannot honestly be collapsed into “the chain handled it.” They may define terms, decide review outcomes, manage manual or delayed fulfillment, post proof, handle exceptions, and close out the record. That does not make the system weak. It makes the responsibility explicit. Yokefellow is stronger when the platform clearly distinguishes between what contracts enforce, what the indexer makes visible, and what operators are still responsible for carrying through.
6. Offering Modes
An offering mode describes the kind of participation path an offering creates. The mode does not describe what the participant ultimately receives, how much entry costs, how the result is selected, or how fulfillment resolves. Those are separate layers. At the tool level, mode sits alongside price rule, selection mode, fulfillment mode, publishing controls, output pool configuration, and eligibility or application configuration. The current offering mode set is purchase, earned, request, application, and grant. These modes matter because Yokefellow does not treat every offering as a sale and does not force every participation path into the same shape.
6.1 Purchase
A purchase offering is the direct exchange path. The participant enters by satisfying the stated economic terms under the offering’s configured conditions. Purchase is the clearest mode because entry happens through payment rather than through review, operator assignment, or open-ended qualification.
At the system level, purchase mode is appropriate when the offering should be available through straightforward paid participation. What matters mechanically is that payment is the entry condition. That does not mean the result must resolve instantly. A purchase offering may still work with different price rules, different output-selection logic, and different fulfillment modes afterward. Purchase tells Yokefellow how the participant gets in. It does not, by itself, decide how the result is selected or fulfilled.
6.2 Earned
An earned offering is a participation path unlocked through action, achievement, contribution, completion, score, or another qualifying behavior rather than through direct payment alone. In this mode, the participant does not simply buy entry. The system or operator recognizes that the participant has met the condition required to enter the path.
Mechanically, earned mode matters because it separates qualification from price. An earned offering may still carry later fulfillment logic, but the path begins through recognized qualification rather than through straightforward paid entry. That is what distinguishes it from purchase.
In practice, earned paths may depend on more specific qualification logic than “did something good.” The system can evaluate threshold-based, event-based, count-based, or streak-based qualification rules, and it can also govern repeatability through policies such as one-time, repeatable, event-scoped repeatability, or cooldown-based reuse. That means earned mode is not only a label for merit. It is a structured qualification path.
6.3 Request
A request offering is a path where the participant asks to receive the offering, but the request itself does not yet mean the result is approved or issued. The participant initiates the process, and the system records that request as distinct participation state that may later be accepted, rejected, fulfilled, or otherwise resolved.
Request mode matters because it introduces a visible intermediate state between entry and completion. The participant has entered the path, but the path is not finished yet. This lines up with the current SDK surface, where request-based participation is represented by createBucketOfferingRequest(...) and then confirmed through returned request state rather than being treated like an instant purchase. Request therefore differs from purchase because entry is not the same as completion.
6.4 Application
An application offering is a path where the participant submits themselves for consideration under criteria that are expected to be evaluated. In this mode, the participant is not only requesting an outcome. They are entering a selection process. The application is therefore not simply demand signaling. It is a structured candidate path that expects review.
Mechanically, application mode matters because the system has to preserve the difference between entry and approval. A participant may satisfy the conditions to apply and still not be selected. That is not a failure of the system. It is part of the mode. Application is appropriate where fit, capacity, or judged eligibility still shape who should receive the result.
6.5 Grant
A grant offering is a path where the offering is assigned by operator or system decision rather than bought, earned through open qualification, or entered through participant request. In this mode, the participant receives the offering because it is granted to them. The key point is that entry does not begin with the participant triggering the path. It begins with an assigning decision inside the system.
Grant mode matters because Yokefellow needs a clean way to represent discretionary distribution without pretending it was a purchase, a request, or an earned unlock. A grant can still be structured, conditional, and visible. What makes it different is the origin of the path. The participant is receiving the offering through assignment rather than initiating it themselves.
6.6 What mode does not do
Offering mode should stay in its own lane. It does not decide price rule, output selection, or fulfillment posture. In the tool, those are separate option families. It also does not mean every offering interaction in the SDK is a separate mode. For example, the current SDK has craftBucketOffering(...) as an offering participation write, but craft should not be treated as a sixth canonical offering mode beside purchase, earned, request, application, and grant. It is a participation flow the app may use, not the canonical mode set itself.
6.7 Eligibility and Repeatability
An earned path is not defined only by what kind of action qualifies. It is also shaped by whether that path can be used more than once and under what limits.
Some earned paths are effectively one-time. Some are repeatable. Some may repeat once per relevant event. Some may be governed by cooldown windows. These limits matter because they change whether the offering is best read as a one-off recognition path, a recurring participation loop, or a paced achievement path.
7. Pricing Modes
A pricing mode describes how an offering determines the amount required for entry, or whether entry has a price at all. In the real tool, price rule is its own option family at the offering layer. It sits beside mode, selection mode, fulfillment mode, publishing controls, output configuration, and any eligibility or application setup. The current pricing set is free, fixed YES, and dynamic USD. These distinctions matter because Yokefellow is not trying to flatten every offering into the same economic shape, and the tool already treats pricing as separate from both participation path and fulfillment posture.
7.1 Free
A free offering has no direct price attached to entry. In the tool, that does not mean the offering has no structure, no gate, or no conditions. It only means the participant is not satisfying entry through a priced amount. A free offering may still use request, application, manual review, delayed resolution, eligibility logic, or other constraints. Free therefore describes the economic terms of entry, not the full logic of the offering.
7.2 Fixed YES
A fixed-YES offering stores a specific YES amount as its price. In the tool, this is the direct YES-priced path. The operator sets the YES amount, and the system treats that amount as the required entry amount until it is changed. The Rights paper’s tool map also notes that fixed YES can be entered as human YES or raw YES, which shows that this is not only paper language but an actual configuration family in the offering surface.
Mechanically, fixed YES is appropriate when the operator wants the offering priced directly in YES rather than derived from a changing reference value. The participant sees the YES amount the offering requires, and the system evaluates entry against that stated amount. The rest of the offering still remains separate: mode defines the participation path, selection mode defines how the result is chosen, and fulfillment mode defines how that result resolves.
7.3 Dynamic USD
A dynamic-price offering stores a USD target and resolves that target into a YES amount using the platform’s YES pricing model. In the current tool language, the dynamic option is the 24-hour EWMA model. That means the participant is still satisfying the offering in YES, but the YES amount is not one permanently fixed number. It is computed from the stored USD target under the current pricing rule.
The Rights paper’s tool map also makes clear that this dynamic model may carry operational guardrails such as lookback window, half-life, minimum trades, and minimum YES volume. Those settings do not change the basic category of the price rule, but they do show that dynamic USD is a governed pricing path in the real tool rather than a vague “market price” idea.
Mechanically, dynamic USD is appropriate when the operator wants the offering anchored to a USD reference while still being paid through YES. That preserves a more stable reference point without turning the offering into a separate USDC-denominated participation flow. It also means users should understand that the required YES amount may move over time even when the offering itself remains the same.
7.4 Why the distinction matters
These pricing modes are not doing the same job. Free says there is no direct priced entry. Fixed YES says the operator wants the offering priced directly in YES. Dynamic USD says the operator wants the offering anchored to a USD value while still being satisfied in YES. In the tool, that distinction is important because price rule is its own offering-layer option family. It does not decide whether the offering is purchase, earned, request, application, or grant. It does not decide whether selection is fixed, choice, or random. It does not decide whether fulfillment is auto mint, pending request, manual review, or delayed resolution.
8. Output Selection
An output-selection mode describes how an offering determines which output resolves once the participation path reaches resolution. In the actual offering tool, output selection is configured separately from offering mode, pricing, and fulfillment. The current output-selection set is fixed, choice, and random. These distinctions matter because not every offering is meant to resolve the same way. Some offerings should always lead to one defined output. Some should let the participant choose among valid outputs. Some should resolve from a defined weighted set under rules the offering already establishes.
In the tool, an offering does not only point vaguely at a class. It is configured through one or more offering outputs. Each output points to an NFT class, but it also carries its own offering-level settings. That is why output selection should be described as selection among configured outputs rather than only as selection among classes in the abstract.
8.1 Fixed
A fixed-selection offering resolves to one configured output. The participant is not choosing among multiple outputs, and the system is not resolving across a weighted set. The result is already determined by the offering design.
This matches the current editor directly. When selection mode is fixed, the output section is treated as one output, and the UI language is essentially: the offering resolves to this class. In other words, the offering is configured to point at one output path from the start.
Mechanically, fixed selection is appropriate when the offering is meant to lead to one known result. That keeps participant expectations cleaner: the participant is entering a structured path toward a defined output rather than toward a menu or weighted pool. Fixed selection does not mean fulfillment must be instant. It only means the output itself is already determined before fulfillment begins.
8.2 Choice
A choice-selection offering resolves from a defined set of valid outputs, but the participant selects which one they want from that set. The offering is still structured by the bucket and operator. The participant is not inventing a new result. They are choosing among outputs the offering already makes available.
This is also visible in the current implementation. The request and participation writes can carry a selectedOutputId, which means the participant is not only entering the offering but may also be selecting one of its configured outputs. That makes choice selection a real part of the offering flow, not just paper language.
Mechanically, choice is appropriate when multiple outputs are intentionally offered under one participation path and the participant should be allowed to decide which one resolves for them.
8.3 Random
A random-selection offering resolves from a defined output set through weighted system resolution rather than through one fixed result or participant choice. The important point is that the output set is already known and configured in the offering. The system is not inventing a result from nowhere, and it is not treating every possible output as equally likely unless the configured weights make them equal.
This is reflected directly in the editor. When selection mode is random, the output summary is weighted outputs, and each output row exposes a weight field. The result is therefore not just “something from the pool.” It is resolution across a pool whose weights are part of the offering design.
Mechanically, random selection is appropriate when the offering is meant to resolve probabilistically across a structured set of outputs.
8.4 Offering outputs
This is the part that should be explicit because it is where the real tool is more specific than the paper.
In the current model, an offering output includes more than just a class reference. It carries its own offering-level configuration, including whether the output is active, its sort order, weight, optional stock limit, optional label override, optional image override, and metadata. That means two outputs inside the same offering may not behave identically even if they both point into the same broader collection-and-class system underneath.
This is why output selection should not be explained only as “the offering resolves to a class.” The class still matters, but the selection logic is governed at the offering-output layer.
Limits may also stack across layers. An offering may be limited at the offering level, at the output level, and again at the class level, which means valid resolution depends on more than one cap being respected at once.
8.5 Active outputs and valid resolution
The live resolution flow also makes one thing clear: the system resolves from active outputs, not from every output record blindly. When request resolution runs, it loads the offering’s outputs, filters to active outputs, and then resolves according to the selection mode and any selected output supplied by the participant.
That matters mechanically because the output pool is not just a passive list. It is a governed set of valid result candidates.
8.6 Why the distinction matters
Output selection needs to remain its own layer because it solves a different problem from the surrounding mechanics. Offering mode answers how the participant enters. Pricing answers what entry costs. Output selection answers how the result is determined. Fulfillment answers how that result is actually issued or resolved.
9. Fulfillment Modes
A fulfillment mode describes what happens after the participation path has been entered and the output has been determined. In the actual offering tool, fulfillment is configured separately from offering mode, pricing, and output selection. The current fulfillment set is:
auto_mint
pending_request
manual_review
delayed_resolution
That is the real enum used by the editor, the API routes, and the database.
What matters here is that fulfillment is not just descriptive language. At least some of these modes change which routes the system allows and how the request flow behaves.
9.1 Auto mint
auto_mint is the one fulfillment mode with the clearest hard behavior in the current code.
If an offering is:
mode = purchase
fulfillmentMode = auto_mint
then it can use the buy route directly.
That is enforced in code. The instant-buy flow checks for exactly that combination, and the bucket page labels it as Instant buy. If that combination is not true, the normal buy route is rejected.
So this is the cleanest fulfillment path in the real tool: the user enters the offering, the flow succeeds, and fulfillment happens immediately instead of going into the request lifecycle.
9.2 Pending request
pending_request means the offering creates request state that can be processed later.
This is also real behavior, not just a label. The request queue UI says requests stay pending, approved, or rejected there, and mint execution moves to the mint queue only after someone explicitly queues it.
That means pending_request is the clearest non-instant fulfillment path in the current tool: the user enters the path, a request row is created, and the result waits in the request flow instead of resolving immediately.
9.3 Manual review
manual_review is a real fulfillment option in the editor and route schema, and its editor description is: Require operator review before fulfillment.
That matches how the current request-resolution flow behaves operationally. The queue lets an operator approve or reject requests before mint work is sent forward.
The important thing to say accurately is this: in the current repo, manual_review is a real configured fulfillment mode, but it does not have a completely separate engine from the request lifecycle. It still runs through the same request queue and operator actions. So its meaning is real, but its implementation is currently expressed through the request-review flow rather than through a totally separate fulfillment system.
9.4 Delayed resolution
delayed_resolution is also a real fulfillment option in the editor and route schema, and its editor description is: Accept now and resolve the outcome later.
That is the right way to describe it in the paper too. But the important repo-grounded truth is similar to manual review: in the current implementation, delayed resolution exists as a configured fulfillment mode, but it does not have a deeply separate downstream engine yet. It still ends up living inside the broader request / operator-handled flow rather than branching into a fully unique resolution system.
So the honest way to describe it is: the offering is accepted now, but final outcome is expected later, and the current tool expresses that through the same broader request-handling structure.
9.5 What the request flow actually does
In the current fulfillment flow, approval and mint execution are related but not identical steps.
A request may be created first and remain unresolved. An operator may then approve or reject it. If the operator moves the request forward into fulfillment, the system resolves the output, creates or ensures the necessary mint records, and sends mint work into the mint queue. The request and the mint are therefore connected, but they are not the same object and they do not represent the same stage of the flow.
This distinction matters because a non-instant offering does not move directly from request creation to finished mint in one step. Request handling and mint execution are separate parts of the same broader fulfillment path.
9.6 What fulfillment mode actually changes
A fulfillment mode tells the system whether the offering resolves immediately or moves through a later handled path.
That is the practical distinction the user and operator need to understand. Auto mint means the path resolves directly when its conditions are satisfied. Pending request means the system creates request state first. Manual review means operator judgment still stands between entry and completion. Delayed resolution means the result is intended to resolve later rather than immediately.
These modes matter because the same broad right can feel very different depending on when it becomes usable and how much later handling still stands between entry and final result.
10. Collections, Classes, and Issuance
Collections, classes, and issuance make up the output layer of Yokefellow. This is the part of the system that turns a resolved participation path into a concrete result the platform can track and the participant can carry forward. The key distinction is that Yokefellow does not treat every output as a one-off mint with no surrounding structure. Outputs are organized, typed, and issued through a layered model so the system can stay legible as offerings become more varied.
10.1 Collection
A collection is the grouped container for related outputs. It is the level at which a family of outputs is organized together under one contract-backed context. A collection matters because the system often needs to treat multiple outputs as belonging to one broader surface rather than as isolated items with no relationship to each other. In other words, the collection is the grouped frame that sits above any one specific output type.
Mechanically, the collection gives the system a place to organize outputs that belong together while still allowing those outputs to differ in class, selection logic, fulfillment path, or right carried. Without that grouping layer, the output side of the system becomes much harder to reason about once more than one kind of result exists inside the same initiative or offering family.
10.2 Class
A class is a defined output type inside a collection. Where the collection groups related outputs together, the class distinguishes one structured type from another within that grouped set. Classes matter because the system often resolves not only to “something in the collection,” but to a specific output type with its own identity, utility, and selection path.
Mechanically, class is the level where the output starts becoming specific enough for the system to use in selection and fulfillment. A fixed output may resolve to one class. A choice offering may let the participant select among several classes. A random offering may resolve across a weighted set of classes. This is why the class layer matters more than as a naming convenience. It is one of the points where the output logic actually becomes concrete.
10.3 Issuance
Issuance is the broader process through which a resolved participation path becomes an assigned output, right carrier, or NFT-backed result. Minting may be part of issuance, but issuance is the larger concept. It includes the full step where the system takes a selected and fulfillable result and turns it into something actually assigned or produced for the participant.
Mechanically, issuance matters because the system needs a term that covers more than immediate minting. Some outputs are auto-minted. Some are queued first. Some are operator-reviewed. Some resolve later. Treating all of those as if they were the same thing would make the system harder to explain. Issuance is the cleaner system term because it covers the broader resolution process without pretending every valid outcome becomes an instant mint.
10.4 Minting inside issuance
Minting is one possible event inside issuance, not the whole output layer. When minting occurs, the system produces the NFT-backed output that carries the relevant right or result. But not every issuance path reaches that point in the same way or at the same time. Some paths mint immediately. Some mint after request processing. Some mint after review. Some may resolve later under delayed-resolution logic.
This distinction matters because Yokefellow is broader than an instant-mint platform. The participant may enter through different offering modes, the result may be selected in different ways, and fulfillment may take different paths before issuance becomes final. Keeping minting inside the larger issuance concept lets the system explain those differences cleanly without making the output layer sound simpler than it really is.
10.5 Input Rules and Craft Paths
Some offering paths do not begin only from price or qualification. They may also depend on previously issued outputs as inputs.
In the current tool, an offering may carry input rules that require specific NFT classes in specific quantities before the path can continue. These rules distinguish between hold requirements and burn requirements. A hold requirement means the participant must possess the required inputs but does not consume them. A burn requirement means the required inputs are consumed as part of the path.
This matters mechanically because a right may function not only as an output, but also as a prerequisite, an ingredient, or a transformation input for a later offering. A holder may need to possess one or more rights, or consume one or more rights, in order to unlock a later result.
Craft paths therefore belong inside the same offering and issuance model rather than outside it. They are not exceptions to the mechanics. They are one of the clearest examples of how earlier issued outputs can become part of a later structured participation path.
A craft path can still resolve through the normal output-selection layer. That means the resulting output may still be fixed, chosen from a valid set, or resolved from a weighted output pool. What changes is the entry condition: the participant is not only satisfying price or eligibility. The participant may also be satisfying required input rules.
10.6 Why the output layer is structured this way
The output layer needs this structure because Yokefellow is built to support many kinds of participation paths without losing clarity. Collections group related outputs. Classes define specific output types. Issuance turns a resolved path into an actual result. Minting can happen inside that process where appropriate. When those distinctions are kept clear, offerings become easier to understand, output selection becomes easier to explain, and fulfillment becomes easier to separate from the result itself.
11. Bucket Permissions and Bindings
Permissions and bindings are the part of the system that answer a simple question: who or what is allowed to act in relation to a bucket, and how is that relationship attached to the bucket in a way the rest of the platform can understand. This matters because Yokefellow does not treat control, rights, and access as free-floating concepts. If an offering, NFT, operator action, or system flow is meant to have meaning inside a bucket, that relationship needs to be anchored somewhere. Bindings are how the system does that.
11.1 Permissions at the bucket level
A bucket is not only a participation surface. It is also a control surface. That means the system needs a way to express who can configure offerings, manage related outputs, fulfill actions, review requests, or otherwise act in ways that affect the bucket’s behavior. Permissions are the structured expression of those allowed actions. They keep control legible instead of leaving it to assumption.
Mechanically, permissions matter because a bucket can hold more than one kind of relationship at once. A participant may hold rights that matter to the bucket. An operator may hold authority to configure or fulfill. A related output may carry a permission surface into a later action. The system therefore needs permission language that is specific enough to attach control to the right context instead of treating all access as the same thing.
11.2 What a binding is
A binding is the structured link that attaches a right, NFT, permission, or control relationship to a bucket or other target context. The key idea is attachment. A right or control only becomes meaningful inside the system when the platform can tell what it is linked to and where that linkage applies. A binding is what gives that linkage system shape.
Mechanically, a binding is what prevents the platform from treating outputs and permissions as abstract objects with unclear scope. If an output is meant to matter for one bucket, the binding makes that relation explicit. If a permission is supposed to apply within one bucket and not across the whole platform, the binding gives the system the context it needs. In that sense, bindings are part of how Yokefellow keeps rights and control surfaces from becoming ambiguous.
11.3 Why bindings matter for rights and issuance
Bindings matter for rights because many rights are not meant to exist in isolation. They are meant to have force inside a specific bucket, initiative, or related surface. The same is true for issuance. An issued output may carry meaning because of what it is bound to, not only because it exists. Without bindings, the platform could produce outputs but would have a harder time expressing where those outputs actually matter.
This is also why permissions and bindings belong together in the mechanics model. Permissions answer what can be done. Bindings answer where and in relation to what that meaning applies. The platform needs both. A permission without context is too broad. A bound right without a recognizable control relation is too weak. Together they let the system attach authority and user value to the right bucket surface.
11.4 Why this layer stays distinct
Permissions and bindings need to remain a distinct layer because they solve a different problem from the surrounding mechanics. Offering mode answers how the participant enters. Pricing answers what entry costs. Output selection answers how the result is determined. Fulfillment answers how the result resolves. Collections and classes organize outputs. Permissions and bindings answer how control and meaning attach to a bucket once those other layers are in motion.
12. Queue Logic and Operator Flows
A queue exists when the system needs to preserve work that should not be treated as instant, invisible, or already complete. In the actual tool, queue logic is not one vague holding area. It is split between the request queue and the mint queue, and those two queues do different jobs.
The request queue is where offering requests stay while an operator decides what should move forward. The mint queue is where mint work sits after it has already been approved and turned into mint-job work. That distinction matters because the real tool does not collapse “approved,” “fulfilled,” and “minted” into the same thing.
12.1 Why queueing exists
Queueing exists because the offering flow is not always instant. A participant may enter a valid path and still not be done. The tool needs somewhere to hold work that is real but unresolved.
In the current implementation, that unresolved work is shown as request rows first. Those rows can be reviewed, approved, rejected, or moved forward into mint work. The queue is therefore not just a backlog. It is the visible system state between entry and final result.
12.2 The request queue
The request queue is the first holding area for non-instant offering work.
It is where offering requests remain while the system or operator decides what should happen next. A request in this queue is real participation state, but it is not yet the same thing as completed mint execution. The request queue therefore exists to preserve unresolved participation in a visible and manageable form.
This matters because not every offering should move directly from entry to issuance. Some paths need review, decision, or later processing first. The request queue is where that unresolved work stays visible.
12.3 What operators can do in the request queue
The request queue is where operators decide whether unresolved participation should move forward.
In practical terms, that means the operator can review a request, reject it, or move it forward toward fulfillment. What matters most is not the exact internal status wording, but the structural distinction: the request queue is the decision layer. It is where the system preserves the fact that participation happened while still leaving room for review, approval, rejection, or later advancement.
This is why request handling should not be collapsed into mint execution. A request may be recognized, reviewed, and advanced without the final mint having happened yet.
12.4 The mint queue
The mint queue is the second holding area. It is for mint work that already exists and still needs to be executed.
This means the mint queue is not where the system decides whether a request should move forward in principle. That decision belongs earlier in the request flow. The mint queue exists after that point, when the required mint work has already been created and now needs to run, retry, or finish.
The distinction matters because approval and execution are different jobs. The request queue handles decision. The mint queue handles production.
12.5 Approval, Fulfillment, and Mint Execution
Approval, fulfillment, and mint execution should be read as connected but separate stages.
A request may first be created and reviewed. If it is allowed to move forward, the system can then prepare the mint-side work associated with that request. Actual mint execution happens after that point. In other words, fulfillment does not mean every later step has already completed in the same instant. It means the request has been advanced into the part of the flow where mint work can be produced and executed.
This is one of the most important distinctions in the queue model. A reviewed request, a fulfilled path, and a minted output are closely related, but they are not identical stages of the same process.
12.6 Request queue versus mint queue
The request queue is for review and decision. The mint queue is for execution.
That is the clearest way to describe the difference.
The request queue tells the operator what still needs judgment or advancement. The mint queue tells the operator what mint work still needs to run or finish. These queues belong to the same broader fulfillment system, but they do different jobs and should not be described as if they were interchangeable.
12.7 Why queue logic stays distinct
Queue logic needs to remain its own layer because it solves a different problem from the surrounding mechanics.
Offering mode answers how the participant enters. Pricing answers what entry costs. Output selection answers how the result is determined. Fulfillment answers whether the result is immediate or later-handled. Queue logic answers where unresolved work lives and how it moves toward completion.
That distinction is what keeps non-instant participation legible instead of letting it disappear into vague “pending” language.
12.8 Payment Reservation, Capture, and Release
Request-handled participation may also carry its own payment lifecycle. A path may reserve value before final resolution, later capture that value if the request moves forward, or release it if the request does not resolve into a completed result.
This matters because payment state and fulfillment state are related but not identical. A request can be real before payment is final, and payment can be reserved before output issuance is complete. Keeping those stages distinct helps the system avoid treating every non-instant path as if it were economically final from the first click.
13. Activity, Receipts, and Indexing
Activity, receipts, and indexing are the visibility layer of Yokefellow. They do not create the underlying participation, pricing, selection, fulfillment, or issuance logic. They make that logic visible in forms people can actually use. Activity is the readable onchain history surface. Receipts are operator-uploaded records attached to the bucket. Indexing is the process that turns supported chain activity into readable platform history. These three layers belong together because a bucket needs both system-visible history and operator-supplied records to remain understandable over time.
13.1 Activity
Activity is the bucket’s visible onchain history surface. Its job is to show the indexed chain-backed actions Yokefellow can surface directly, so participants and operators can see what has happened in relation to the bucket without needing to read raw contract data.
Mechanically, activity is where supported onchain actions become bucket-facing history. It is the readable surface for things like deposits, trades, mints, payouts, and other indexed events the platform can attach to the bucket. Activity therefore gives the bucket a public chain-history layer that is useful to read, not just technically true.
13.2 Receipts
Receipts are operator-uploaded records attached to a bucket. Their job is to preserve real-world supporting information that the chain does not and should not carry on its own.
Sometimes a receipt shows what money was spent on. Sometimes it records what happened around an event, a fulfillment step, a vendor relationship, or another execution detail tied to the initiative. The important point is that receipts are a document surface. They are how the operator adds supporting records to the bucket when the relevant information is not an onchain event.
13.3 Indexing
Indexing is the process that ingests supported onchain actions and turns them into readable platform history. It is what allows Yokefellow to take raw chain activity and surface it as the activity users see on the bucket and related parts of the system.
Mechanically, indexing matters because the platform needs a way to translate contract activity into bucket-facing history. It does not replace receipts, and it does not create operator records. Its job is narrower and cleaner than that: make supported onchain activity readable inside Yokefellow.
13.4 Why the distinction matters
These three layers do different jobs. Activity is the visible onchain history surface. Receipts are operator-uploaded records. Indexing is the process that makes supported onchain activity readable inside the platform.
Keeping that separation clear matters because a bucket may need both kinds of record at once. People need to see what happened onchain, and they may also need uploaded records that explain spending, execution, or other real-world details tied to the initiative. When those roles stay distinct, the bucket becomes easier to read and easier to trust as a long-lived record of both platform activity and bucket execution.
14. Design Principles
The mechanics of Yokefellow are built to keep participation structured, legible, and expandable. The system is not trying to force every initiative into one rigid pattern. It is trying to make very different initiatives readable through the same core logic. That is why this paper keeps separating layers that are often blurred elsewhere. Offering mode, pricing, output selection, fulfillment, issuance, queueing, and indexing all do different jobs. The system stays clearer when those jobs stay distinct.
A second principle is clear role separation. Participants, operators, buckets, offerings, outputs, and bindings are not interchangeable. A participant enters a path. An operator configures or fulfills where the system calls for it. A bucket holds the participation surface. An offering structures entry. A class defines an output type. A binding attaches meaning or control to the right context. These roles matter because Yokefellow is trying to reduce ambiguity, not hide it behind softer language.
A third principle is flexible outputs without vague promises. The system needs to support fixed results, participant choice, and weighted random resolution. It needs to support immediate issuance, pending states, review-dependent resolution, delayed outcomes, and input-driven craft paths. Flexibility is therefore part of the design, but it is meant to be explicit flexibility, not loose improvisation.
A fourth principle is operator accountability without pretending operators disappear. Yokefellow uses contracts, indexing, and system structure where those things are the right tools, but it does not pretend every meaningful action is fully automatic or fully onchain. Operators still matter. They define terms, manage certain flows, upload receipts, post proof, and carry responsibility where the system cannot honestly reduce work to contract events alone. The platform is stronger when that responsibility is named clearly instead of being hidden.
A fifth principle is reusable primitives. Buckets, offerings, rights surfaces, collections, classes, issuance, queues, and indexed history are not one-off features. They are the repeatable parts that let Yokefellow support very different initiatives without rebuilding the system from scratch each time. That reuse is what makes the platform broader than a single participation surface while still letting the mechanics remain coherent.
A sixth principle is multi-app expandability. The mechanics are not meant to belong to one site, one interface, or one narrow use case. They are meant to support more than one surface while keeping the same internal logic. That is why the paper focuses so heavily on system roles, system layers, and system distinctions. Yokefellow scales better when the mechanics are stable enough that new surfaces can build on them without changing what the underlying system means.
The practical rule is simple: keep the mechanics explicit enough that different surfaces can build on the same engine without changing what the engine means.