Yokefellow - How Yokefellow Works
Operator Manual
A practical guide for operating live buckets, configuring offerings, managing queues, attaching proof, and keeping public surfaces legible.
1. What This Manual Is
This manual is the practical operating guide for running a live bucket responsibly. It is written for bucket owners, operators, team members, and creators who need to configure offerings, manage permissions, process issuance work, handle review paths, move bucket credit carefully, and keep the bucket legible and trustworthy over time. It is not the Whitepaper, not the Mechanics paper, and not the Architecture Spec. Its job is narrower: how to operate the live bucket surface well.
The current repo reflects a real operator workspace rather than one flat abstract admin surface. In practice, operators work through distinct blocks: the public bucket page, bucket access and bindings, issuance and queues, offerings, NFT tools, and finance and status. Those blocks do different jobs, and this manual is about using each of them correctly instead of blending page copy, control logic, issuance work, and finance reading into one vague operator habit.
This manual sits at the live operating layer of Yokefellow. Mechanics explains how the system behaves. Architecture explains the contract stack, trust boundaries, and where durable enforcement lives. Rights & Offerings explains what users are actually being offered and what those rights mean. The Operator Manual explains how an operator turns that structure into a well-run live bucket through configuration, review, queue handling, fulfillment, receipts, corrections, and closeout.
That distinction matters because Yokefellow is not fully automatic and not fully onchain. Some paths are immediate. Some create pending request state. Some depend on review, queue progression, later mint work, or other operator-managed steps. This manual exists to make those live responsibilities explicit and to help operators run them in a way users can actually understand.
2. Read the Real Operator Surface First
Before changing anything, read the operator surface the way the product now exposes it. The bucket workspace is not one flat settings page. It is broken into distinct operating blocks because different kinds of mistakes happen when page framing, bucket-scoped control, issuance work, offering structure, carrier setup, and finance review all get blended together. The operator surface is clearer and safer when each kind of work stays in the block that actually owns it.
The safest operating rule is simple: do work in the block that actually owns that kind of work. Do not try to fix queue problems with page copy. Do not try to fix offering structure with a receipts post. Do not treat collection setup as if it were only a cosmetic media step. Do not treat a finance read as if it were the same thing as fulfillment or closeout.
2.1 Bucket page
Use the page editor for the public story of the bucket: what it is, what it is for, what users should expect, what is immediate, what is pending, and where stable rules live. This is where vague, stale, or overbroad framing should be fixed first. The page should not promise a cleaner or faster path than the actual offering and fulfillment setup can support.
2.2 Bucket access & bindings
Use the bindings block when a right, NFT, permission, or ownership relationship should have force inside one specific bucket context. This is the bucket control layer. It is where authority and bucket-scoped meaning are attached to the right surface. It is not the marketing layer, and it is not where broad product meaning should be implied without an actual bucket attachment.
2.3 Issuance & queues
Use the queues block when the work is operationally pending. Request state and mint state are not the same thing, and they should not be run as if they were one pile of generic backlog. The request queue is the decision layer: review, approval, rejection, or later advancement. The mint queue is the execution layer: mint work that already exists and still needs to run, retry, or finish.
2.4 Offerings
Use the offerings block to define how participation enters the system. Mode, pricing, selection, output pool, fulfillment posture, and the user-facing path all belong here. This is the place to make the participation path legible before the user acts, not the place to patch confusion later with updates or private explanation.
2.5 NFT tools
Use the NFT tools block for the carrier layer itself: collections, classes, metadata, transfer rules, burn behavior, supply limits, ownership controls, and mint readiness. This is where the output should be made durable and operationally ready before it is made public. A path should not go live before the carrier layer is actually capable of supporting it.
2.6 Finance & status
Use the finance and status block as a read and checking surface. Operators should review it regularly, especially before making claims about raise progress, bucket balances, funding posture, or current operating state. It is the place to verify what the bucket currently shows, not the place to blur together funding lifecycle, fulfillment, and operator judgment.
2.7 A simple operating cadence
A bucket runs better when the operator works on a rhythm instead of only reacting when something feels late. The exact cadence can vary by bucket size, but the discipline should stay visible enough that review state, queue state, public framing, finance state, updates, receipts, and proof do not drift apart. A good cadence also checks whether pending work is actually fulfillable before more of it is advanced.
| Moment | What to check | Why it matters |
|---|---|---|
| Daily or every live session | Request queue, mint queue, new pending review items, obvious user-facing blockers. | Prevents silent backlog and keeps in-between state legible. |
| At least weekly | Bucket page accuracy, live offerings, stock posture, finance and status surfaces, stale updates. | Keeps the public surface truthful while participation is still open. |
| Before opening a new path | Collection linkage, class controls, output pool, pricing, fulfillment posture, payment behavior. | Prevents operators from launching a path whose carrier or money behavior is not actually ready. |
| After major fulfillment or spend | Receipts, proof, relevant updates, and any policy correction that the public record now needs. | Makes follow-through readable instead of leaving the record trapped in private explanation. |
| Before closeout | Unresolved pending rows, incomplete issuance, missing receipts, stale status, and anything the public surface still cannot answer. | Closeout is only credible when the record can explain what happened without reconstruction. |
3. Start with the Bucket, Not the Feature
A bucket is the core participation surface in Yokefellow. It is not just a page, not just a wallet, and not just a treasury. It is the surface that holds the initiative, the participation paths, the public framing, and the later record together. That is why operators should start with the bucket before they start thinking feature-first. If the bucket is vague at the top level, the rest of the configuration usually becomes muddy with it.
A strong bucket should answer the basic public questions before deeper setup begins. What is this initiative. What are participants actually showing up for. What kinds of participation paths belong here. What kinds of outputs, rights, or NFTs may come out of it. What proof, receipts, or visible closeout should exist later. If those questions are still unclear, the operator is usually trying to configure structure before the bucket itself is legible.
The practical rule is simple: define the bucket clearly before tuning the feature layer around it. Offerings, classes, queue handling, funding posture, and operator rules should sharpen the bucket’s purpose, not substitute for it. A bucket that cannot be explained plainly is not ready for live participation, because the user-facing meaning of everything inside it will stay unstable.
4. Creating a Bucket
Creating a bucket is not only a setup step. It is the first trust decision in the live operating flow. In the current product, a new bucket begins as a draft, not as a participation-ready surface. That matters because a bucket is not just a record in the system. It is the public participation surface that will later carry offerings, funding posture, policy, proofs, and closeout together. A bucket should therefore be created as something the operator intends to make legible, not as an empty shell that will somehow become clear later.
A good creation rule is simple: one bucket, one readable purpose, one honest draft before publication. If the operator cannot explain what the bucket is for, who is responsible for it, and what kind of participation surface it is supposed to become, the scope should be tightened before the bucket is opened further.
4.1 Core identity and ownership
The first step is to define the bucket’s core identity and ownership clearly. That means choosing the name, assigning the owner wallet, selecting the chain context, and setting visibility. These are not cosmetic fields. They establish who the bucket belongs to, where it lives, and whether it should appear as a visible public surface or remain internal while it is still being prepared.
This is also the stage to decide whether the bucket has a specific onchain identity already and whether it should be treated as a featured surface later. Those choices should still follow the same operator rule: the bucket title, ownership, and basic posture should match the real initiative rather than trying to make one bucket cover unrelated work just because the system allows broad flexibility.
4.2 Funding posture at creation
Bucket creation already includes a funding posture. The operator should decide up front who can fund the bucket, whether the owner should be able to withdraw or send funds, and whether public deposits should be enabled. These choices shape user expectation early, even before offerings are added.
That matters because funding posture is part of the bucket’s real operating design, not a later technical detail. A bucket where only the owner should fund is not the same surface as one meant to accept public participation deposits. A bucket where treasury movement remains owner-controlled should not be described like a surface with no meaningful operator control. If the funding posture is wrong at creation time, later participation and trust language usually become muddy too.
4.3 Choosing the mechanic early
The mechanic should be chosen at creation time because it affects the whole operating shape of the bucket. The current mechanic set is Manual, Splash, and Leaky, and the choice should be made early and intentionally. Splash buckets should be created with a real target in mind. Leaky buckets should be created with a real pacing posture in mind. Manual buckets should be chosen when the initiative truly needs tighter operator timing and judgment rather than automatic threshold or schedule behavior.
4.4 Draft terms before publish
Before publication, the draft bucket should already answer the basic public questions users will have. In the current create flow, that means filling in the summary, operator, support contact, constraints, and policy reference before treating the bucket as publish-ready.
Those fields matter because they are the minimum terms that let a user understand what the bucket is, who is behind it, where help or questions go, what limits or conditions apply, and where the stable governing rules live. A bucket that exists without those terms may still be a valid draft, but it is not yet a trustworthy public participation surface.
The operator should treat this step seriously. Public copy should not be filler. Summary should state the initiative plainly. Operator should identify the responsible party clearly. Support should give a real contact path. Constraints should state the limits users need before acting. Policy should point to the stable rules surface rather than leaving important conditions scattered across updates or private explanation.
4.5 References and app linkage
A bucket also needs a supporting record structure, not only a headline description. At the draft stage, the operator should decide what the main explainer is, what references the bucket should point to, and how later docs, receipts, and updates will attach to the surface. In practice, that means the primary brief, term references, and the linked content posture should be considered part of setup rather than an afterthought.
If the bucket is app-linked, this is also the stage to attach that relationship clearly. App ID, app slug, app URL, review status, and whether the bucket is managed by an app or SDK should be set when they actually matter to the bucket’s operation. Not every bucket needs those fields, but when app linkage is real, it should be made explicit instead of implied loosely later.
The practical rule is simple: create the bucket as a readable draft with its identity, funding posture, mechanic, public terms, and reference posture already taking shape. Publication should come after that work, not before it.
5. Choosing the Right Mechanic
The mechanic changes how the bucket behaves operationally, so it should be chosen for correctness rather than aesthetics. The current mechanic set is Splash, Leaky, and Manual. The operator’s job is to choose the behavior family that matches the initiative instead of forcing the initiative into the wrong posture. This matters because the mechanic is not just a label in setup. It changes how participation, timing, and value movement are expected to work over the life of the bucket.
Use Splash when the bucket has a meaningful completion threshold. Splash is the right mechanic when the initiative has a defined target, a clear done moment, or a visible threshold that should change the bucket’s posture once reached. It fits buckets where the operator can explain what completion means and what should happen once that condition is met. Operators using Splash should be ready to define the target, the close condition, the fulfillment window, and the proof or reconciliation plan up front. A bucket should not be framed like a threshold-driven surface unless the threshold actually matters to how the bucket will be run.
Use Leaky when the bucket is meant to behave as an ongoing program rather than a one-time raise. Leaky fits recurring activity, continuous support, longer-running participation surfaces, and other cases where paced throughput matters more than one clean completion event. Operators using Leaky should define the pacing rules clearly and remember that ongoing throughput does not remove the need for proof, receipts, visible accountability, or readable closeout logic for each meaningful phase of the bucket’s life. A bucket should not be treated like an ongoing stream unless the operator is actually prepared to manage it as one.
Use Manual when the bucket needs direct operator judgment more than automatic pacing or automatic target logic. Manual fits cases where timing is irregular, outcomes are more discretionary, or advancement should not happen on a fixed schedule or at a single threshold. It gives the operator more control, but it also places more responsibility on the operator to move the bucket forward cleanly, explain state changes visibly, and avoid letting review, fulfillment, or proof drift into silence. Manual is the most flexible mechanic, but it is also the least forgiving of weak operator discipline.
The practical rule is simple: choose Splash for threshold-driven buckets, Leaky for paced ongoing buckets, and Manual for buckets that truly need tighter operator control. If the operator cannot explain why the initiative belongs in one of those behavior families, the mechanic has probably been chosen too loosely.
6. Preparing the Public Surface Before Launch
Before opening participation, make the public surface tell the truth about the bucket and about the state a user is entering. The bucket page should clearly explain what the bucket is, what each live path does, what is immediate, what is pending, what is operator-reviewed, what is delayed by design, and what proof or follow-through should appear later. The page copy should not sound faster, broader, cleaner, or more guaranteed than the actual configuration can support.
This is also where the stable record surfaces matter. Use policy for the durable rules and expectations users should know before acting. Use docs for stable reference material that should remain readable over time. Use updates for movement as the bucket progresses. Use receipts for concrete supporting records tied to execution, spending, vendor work, fulfillment, or other real follow-through. Keep those surfaces cleanly separated. Do not hide durable rules in updates. Do not use receipts as marketing. If a user must know something before acting, that information belongs in policy or docs, not in a future post.
A bucket should not go live with placeholder logic in public. If the fulfillment path is delayed, say so. If the path depends on review, say so. If entering the path creates pending state rather than a final result, say so. If the output is bucket-scoped or app-scoped rather than universal, say so before the user acts. The public surface should make the structure readable enough that the user does not have to reconstruct meaning from scattered screens later.
7. Setting Up Collections and Classes
If the bucket issues NFT-backed outputs, the collection and class layer should be configured before the offering goes live. Operators should know which collection the bucket is using, whether that collection is actually recognized and linked to the bucket context, which classes exist inside it, how those classes behave, and which offering outputs are allowed to resolve into them. Do not publish the participation path first and improvise the carrier later.
The current repo treats this as a real operating layer, not a cosmetic attachment step. Collections, classes, offering outputs, queue-backed issuance, and ownership sync all have to line up for the path to resolve cleanly. That is why the carrier should be treated as launch-critical setup rather than post-launch cleanup. Rights are shaped by bucket context, offering path, carrier layer, control layer, scope, metadata, and code interpretation together, not by the NFT shell alone.
7.1 Create or link the correct collection
The current repo supports factory deployment of bucket-linked collections and linking of existing recognized collections into the bucket surface. In practice, this is a registry-first model. The collection should not only exist onchain. It should be recognized by the collection registry, associated with the right chain context, and linked to the bucket it is actually supposed to serve.
Before launch, confirm four things. First, the bucket has the onchain identity needed for linked collection behavior where applicable. Second, the collection is actually linked to that bucket context rather than merely existing on the same chain. Third, the chosen standard matches the real use case. Fourth, the collection grouping strategy is deliberate. Use 721 when uniqueness or singular identity matters. Use 1155 when quantity, repeatable issue, or class-style accumulation matters. The carrier standard changes how the right behaves in practice, so it should be chosen intentionally.
Treat collection grouping deliberately. In the repo, linked deployment uses a collection group key that becomes the bucket-linked collection key used for organizing related outputs. That grouping should stay stable enough that later classes, offerings, and app reads still make sense together. A drifting grouping strategy usually becomes a management problem later.
7.2 Match class controls to the actual right
Class controls are not technical trivia. They are part of the user-facing meaning of the right. In the current repo, the class layer includes status, transfer mode, mint mode, personalized-per-mint behavior, max supply, max per-wallet limits, metadata JSON, and class capabilities. Those settings help determine what the holder is actually receiving and how the surface is expected to behave. Rights on Yokefellow are shaped directly by controls such as transfer rules, burn rules, mint posture, supply caps, per-wallet limits, metadata controls, and scope.
Operators should therefore treat the class layer as part of the right design itself. If the class should be transferable, say so. If it should be restricted, say so. If it should be soulbound or effectively holder-bound, say so directly. If issuance is supposed to happen instantly, only use the class and offering posture that can really support that. If the class is personalized per mint, that should be intentional rather than accidental.
Operators should also think clearly about what kind of thing the class actually is. Is it a one-off credential, a repeatable issue, a status object, a decor item, a tool key, a proof-bearing object, or an input for a later craft or burn path. The class layer should fit that meaning directly rather than leaving the carrier behavior implied.
Transferability should be stated just as directly. Some outputs are meant to move. Some are narrow, role-linked, or identity-linked and should remain restricted or soulbound in effect. If later resale or broader market reading would be misleading because the output is narrow, consumable, depleted, or bucket-bound in meaning, that should be made visible before issuance. The rights paper is clear here: broad language should not be used for narrow rights, and the boundary should be stated as clearly as the benefit.
7.3 Metadata and image discipline
Images, metadata templates, contract-level URI choices, and label conventions should be treated as part of the user-facing surface. In the current repo, metadata is not only one field. Some of it lives at the collection layer through contract URI or base token URI, and some of it lives at the class layer through metadata JSON and image settings. That means operators should think about metadata as a layered publishing surface rather than as one editor box.
If metadata is still expected to change, do not present the class as if it were already final. If the class image is supposed to matter in-app, test it there rather than only in the editor preview. If metadata fields are what an app uses to interpret the right, then metadata discipline is part of launch readiness, not decoration. A right is not only issued; it is configured, carried, scoped, and interpreted. Metadata is part of that interpretation layer.
7.4 Mint readiness before launch
Before publishing any auto-mint or queue-backed output, test the real mint path. In the current repo, mint execution still runs through server-side queue processing and a server-side signer. More importantly, the mint executor requires the configured signer wallet to match the collection owner for that server-side mint path to work. A valid offering is therefore not enough on its own. Collection ownership, signer readiness, linked collection state, output limits, and queue processing all have to line up before live participation begins.
A practical rule is simple: do not assume a valid offering automatically means a valid mint. If those layers are misaligned, request or purchase state can still be created while final issuance stalls. The operator manual already points at the real failure pattern: if queue-backed issuance depends on stock, class limits, collection ownership, mint readiness, or metadata being final enough to issue, confirm those prerequisites before approving live work. Approval without fulfillability is how preventable backlog turns into trust damage.
8. Designing Offerings Correctly
Offerings are how the bucket makes participation concrete. Each offering should be treated as a structured participation path with a clear user action, a clear expected result, and a clear fulfillment posture. If the operator cannot explain what a participant is entering, what determines the result, and what happens after entry, the offering is not ready. The safest operator rule is to keep the offering layers distinct: mode, pricing, selection, fulfillment, and output pool each do a different job and should not be blurred together in setup or in public copy.
8.1 Mode
Start by choosing the correct participation path. The current mode set is purchase, earned, request, application, and grant. These are not interchangeable labels. Purchase should read like paid entry. Request should read like a visible pending path. Application should read like a selection process. Grant should not be described as if users can self-serve it. Earned should not be described as if the user is simply buying the result.
Keep mode in its own lane. Mode answers how the participant enters the path. It does not decide price rule, output selection, or fulfillment posture. It also does not mean every special flow becomes a new canonical mode. For example, craft may be a real participation flow in the app, but it should not be treated as a sixth canonical offering mode in the bucket tool.
8.2 Pricing
Price answers what entry costs. It does not decide what kind of path the user is entering. The current pricing set is free, fixed YES, and dynamic USD. Free means there is no direct priced entry. Fixed YES means the offering is priced directly in YES. Dynamic USD means the offering is anchored to a USD target while still being satisfied in YES through the platform’s pricing model. In the current tool language, that dynamic path is the 24-hour EWMA model.
Keep that distinction clean in the public description. A dynamic offering should not be described as if the YES amount is permanently fixed, and a free path should not be described as if it has no structure just because there is no direct price.
8.3 Selection
Selection mode should also be explicit. Some offerings resolve into one fixed output. Some let the participant choose among valid configured outputs. Some resolve randomly from a weighted output pool. Those outcomes should not be flattened into one generic promise, because certainty of result is part of the participation path.
The operator should therefore be able to say plainly whether the result is known in advance, chosen from a defined set, or resolved probabilistically from a governed pool. If that answer is still vague, the offering is not ready.
8.4 Fulfillment
The current fulfillment options are auto mint, pending request, manual review, and delayed resolution. Fulfillment tells users what happens after they enter the path. It should be visible in setup and visible in copy.
A simple operator rule is to read fulfillment as a user-state promise. It tells the user whether the result should feel immediate, remain visibly pending, depend on explicit review, or resolve later by design. Fulfillment is therefore part of the right’s visible design, not only an internal workflow concern.
| Pattern | What the user experiences | Operator note |
|---|---|---|
| Purchase + auto mint | The path reads like an instant buy. The user enters, the action succeeds, and the result should resolve without waiting in the request lifecycle. | Use only when the carrier, output pool, and mint path are genuinely ready. |
| Purchase or request + pending request | The user has entered the path, but the result is still pending. The important visible state is the request row, not a finished issuance claim. | Best when later queue handling is expected and should remain visible. |
| Application or request + manual review | The user can enter now, but fulfillment still depends on an explicit operator decision. | Use when approval is a real evaluative step, not when the team is simply late. |
| Any mode + delayed resolution | The user should expect later resolution by design rather than immediate issuance. | Explain what later trigger, review moment, or reconciliation step will advance the path. |
| Earned + queue-backed or review-backed fulfillment | The user has qualified, but the qualified state may still move through request, review, or mint work before the final output appears. | Do not flatten qualification into instant delivery if the configured path still has later operational steps. |
8.5 Outputs and stock
Use the output layer deliberately. Fixed paths should point to the correct output. Choice and random paths should use a real output pool, not a vague promise that will be sorted out later. In the current model, an offering output is not just a class reference. It can also carry active state, sort order, weight, optional stock limit, optional label override, optional image override, and output metadata. That means selection is governed at the offering-output layer, not only at the class layer.
Operators should treat the output pool as a governed live set rather than a passive list. Limits may stack across layers: offering-level limits, output-level stock limits, and class-level caps can all matter at once. Valid resolution depends on more than one layer being aligned. Before launch, confirm that the active outputs are the ones users should actually resolve from, that weights and stock reflect the real path, and that inactive or exhausted rows cannot accidentally be read like live promises. The system resolves from active outputs, not from every output row blindly.
9. Pricing, Payment, and Credit Discipline
Operators should set and describe offering economics in a way users can understand before acting. Free does not mean structureless. Paid does not mean guaranteed issuance. A priced path should make clear not only what entry costs, but also what kind of economic commitment the user is making: whether value is paid immediately, reserved first while the path remains pending, or captured only after later approval, fulfillment, or other resolution. Payment state and fulfillment state are related, but they are not the same thing.
The current repo also makes payment lifecycle visible at the request layer. In request-handled participation, value may be reserved before final resolution, later captured if the path moves forward, or released if the path does not resolve into a completed result. Reserved, captured, and released YES should not be treated like invisible bookkeeping. If a path reserves payment first and captures later, the operator should understand that distinction and write the path accordingly so the user can tell what has actually happened economically and what has not.
The same discipline applies to bucket credit. Deposited, available, reserved, spent, and withdrawable values are not interchangeable. Deposited value has entered the bucket rail. Available value is still free to use. Reserved value has already been committed to a pending action. Spent value has already been consumed by participation or settlement. Withdrawable value answers a different question again. Operators should be able to explain what state the user is in before and after every important step rather than collapsing all of those states into one vague balance number.
This matters even more because deposit behavior can differ by bucket posture. Some buckets behave like stored participation credit, where value remains available until the user commits it later. Others behave more like capture-on-deposit surfaces, where entry itself is already closer to commitment. Operators should understand which posture they are running and describe the user experience accordingly.
10. Earned Paths, Request Paths, Applications, and Manual Review
Conditional and operator-managed paths are useful when the bucket needs a visible state between entry and final issuance. They are not signs that the offering is broken. They are signs that the bucket is using a structured intermediate-state path rather than a simple instant-result path. The operator’s job is to make that state legible, keep the path honest in public copy, and process it responsibly once users begin entering it.
10.1 Earned paths
Earned mode should be used when the path begins through recognized qualification rather than through direct payment alone. In the current repo, earned logic can be event-based, threshold-based, count-based, streak-based, or otherwise qualification-driven. If an offering is earned, define what actually qualifies the user. Do not call a path earned if the qualifying behavior is still undefined or only implied loosely. Earned mode is not a vibe label. It is a structured qualification path.
Repeatability should also be stated directly. A path that works once, a path that can repeat freely, a path that repeats once per relevant event, and a path that is governed by cooldown are not the same experience. Those limits change how the participant should read the opportunity and how the operator should manage it.
10.2 Request and application paths
Use request mode when the participant should be able to enter the path now while the result still needs later processing or resolution. Request mode creates visible intermediate participation state. The participant has entered the path, but entry is not the same as completion. That pending state should remain readable rather than being flattened into a fake instant-success frame.
Use application mode when the participant is entering a selection process rather than a simple queue. An application is not only a request with slower timing. It is a candidate path that expects evaluation, and a participant may satisfy the conditions to apply and still not be selected. That is part of the path, not a system failure. In both request and application flows, users should be able to tell clearly that the path is pending rather than resolved.
10.3 Manual review
Manual review should be used when fulfillment depends on operator judgment rather than only on the participant completing their side of the flow. This is a fulfillment posture, not just an internal team habit. If a path is review-dependent, the user should be able to tell that from the offering surface itself. Review-dependent fulfillment is a real user-state distinction, and it should stay visible.
The key operating rule is simple: do not let review state disappear into silence. Approve, reject, or explain the pending state visibly and on time. Manual review should be used when evaluation is real, not as a cover for weak operator discipline or delayed processing. Operators still own the human parts of the loop, and this is one of the clearest places where that responsibility has to stay visible.
11. Craft Paths and Input Rules
Craft paths should be run as transformation paths, not as disguised purchases. In the current repo, craft still belongs inside the normal offering and issuance model. What changes is the entry condition. The participant is not only satisfying price or qualification. The participant may also need to satisfy configured input rules based on previously issued NFT-backed outputs. That means the operator is not only offering a result. The operator is defining the recipe that makes that result possible.
If an input rule is only a hold requirement, say so plainly. A hold requirement means the participant must possess the required inputs, but those inputs are not consumed. If an input rule is a burn requirement, say so before the user acts. A burn requirement means the required inputs are consumed as part of the craft path. A craft path should never surprise the user about whether the source NFTs are merely checked or actually spent.
Operators should also test the full craft flow before launch. In the current repo, that means more than checking whether the offering exists. Test whether the input rules validate correctly against real holdings, whether burnable inputs require prior approval, whether any request, queue, or mint behavior afterward is functioning, and whether the final transformed result is readable as the output the user was actually trying to craft. A valid recipe is not enough if the live craft path still stalls at approval, burn, request, or mint execution.
12. Managing Bindings and Permissions
Bindings and permissions are where the bucket’s control surface becomes legible. They answer two different questions, and operators should keep that distinction clear. Permissions answer what can be done. Bindings answer where and in relation to what that meaning applies. A good operating rule is to bind meaning where it actually belongs. If an NFT, output, or right is only supposed to matter for one bucket, bind it there. Do not create platform-wide ambiguity around a right or authority that only makes sense in one local context.
The current repo’s permission layer distinguishes between ordinary operational powers and higher-control powers, and operators should grant both sparingly and descriptively. Page editing, posting, offering management, request handling, class management, and similar actions are not the same kind of authority as withdrawal or owner-side chain management. A bucket is not only a participation surface. It is also a control surface, so permission assignment should stay specific enough that people can tell who may configure, fulfill, review, or move sensitive value-bearing actions.
NFT-backed control should be handled carefully. A collection, class, or specific token can become the source of bucket authority, but only when the operator can explain exactly what action that ownership should unlock, why it belongs in that bucket, and what scope it is supposed to have. Ownership alone is not the whole authority model. In the current stack, the ownership fact is one layer, the relevant binding is another, and the derived permission assignment is another. Operators should not assume that a held token automatically means every related power is active everywhere at once.
The practical rule is simple: keep bucket authority scoped, explicit, and interpretable. If the operator cannot explain what the token-backed authority does, where it applies, and why it belongs in that bucket rather than across the whole platform, the binding or permission model is probably still too loose.
13. Running Request and Mint Queues
Queues exist because not every valid participation path should resolve instantly. In the current model, unresolved work does not live in one generic backlog. The request queue is the decision layer. It is where user-side entry remains visible while the system or operator decides whether the path should move forward, remain pending, or be rejected. The mint queue is the execution layer. It is where mint work that already exists still needs to run, retry, or finish. Those are distinct responsibilities and should be run that way.
A good queue posture is steady and visible. Check pending work regularly. Resolve obvious cases cleanly. Do not leave old rows sitting in a permanent maybe-state just because the system technically allows it. Users should be able to tell whether their path is pending, approved, rejected, queued for issuance, or fully resolved. Queue state is part of the platform’s real readability layer, not just an internal operator convenience.
Operators should also remember that approval, fulfillment, and mint execution are connected but separate stages. A request may be real before it is approved. An approved path may be real before mint execution is finished. In some request-handled flows, payment may also be reserved before final capture and before final issuance is complete. Do not collapse those states into one vague “success” frame.
If queue-backed issuance depends on stock, class limits, collection ownership, mint readiness, or metadata being final enough to issue, confirm those prerequisites before you approve large amounts of work. Approval without real fulfillability is how preventable backlog turns into trust damage. That same discipline already appears elsewhere in the manual’s operating cadence: before opening or advancing a live path, confirm that the carrier and money behavior are actually ready.
14. Funding, Withdraws, and Bucket-to-Bucket Movement
Operators should understand the funding lifecycle, not only the bucket headline balance. Deposits, withdraws, and bucket-to-bucket transfers are lifecycle-driven actions. That means preparation, wallet-side approval, signature, or transaction submission, status checks, and final reflected state all matter. These flows are related, but they do not all move through the same shape. Deposit, withdraw, and transfer-between-buckets each have their own lifecycle posture in the current repo, and operators should describe them accordingly rather than flattening them into one generic “balance moved” story.
The current repo also keeps credit semantics visible. Available, reserved, spent, and withdrawable values are not interchangeable. A bucket that behaves as stored participation credit should be run differently from a surface where value is effectively captured on entry. This matters especially when the operator is using an account-style bucket as the funding source for other participation paths. Bucket-to-bucket movement should stay legible so a user can tell where value currently sits and what action has already committed it.
14.1 Funding lifecycle
Funding actions should be read as staged flows rather than one-step events. In the current repo, deposit begins with a prepare step, returns approval and transaction descriptors, then moves through status checks and finalization where required. Transfer-between-buckets follows a similar prepare, transact, status, and finalization pattern. Withdraw is different. It begins with a prepare step that returns a signature payload, then continues through a signed submit step, then status tracking. Withdraw does not use the same explicit finalization path as deposit and transfer-between-buckets.
The operator rule is simple: do not describe funding as complete just because the first request returned successfully. A prepared deposit is not a completed deposit. A signed withdraw request is not the same thing as reflected final state. A transfer between buckets should not be described as done until the tracked lifecycle actually confirms and the affected surfaces reflect it.
14.2 Deposit behavior
Not every bucket should be read the same way after value is deposited. In the current system, some buckets behave like stored participation credit. Others behave more like capture-on-deposit surfaces where entry itself is already closer to commitment than to a reusable balance. Operators should decide which posture they are actually running and describe the user experience accordingly.
A credit-style bucket is the better posture when users need available balance that can later be directed into different offering paths. A capture-on-deposit posture is the better fit when the initiative should treat the deposit itself as the meaningful commitment. The important operator rule is to avoid describing these two behaviors as if they create the same user expectation. Deposit behavior changes what users think “my balance” means.
14.3 Withdraw availability
Where the bucket posture allows withdrawal, that should be represented clearly. Withdrawable value is a distinct state in the current surface, not just a synonym for available value. A bucket may show available balance, reserved balance, spent balance, deposited posture, and withdrawable posture separately, and operators should not collapse those into one vague number.
This matters because user expectation changes depending on what the bucket is for. In a credit-style bucket, users may reasonably read some available value as reusable participation credit and, where the bucket allows it, potentially withdrawable value. In a capture-on-deposit posture, users should not be led to read the resulting state as a freely reusable or freely withdrawable pool if that is not how the bucket is meant to behave. If withdraw is part of the bucket posture, say so. If value is meant to stay committed once deposited, say that instead.
Operators should also remember that withdraw has its own lifecycle shape. In the current repo, withdraw prepares a signable message, requires a signed resubmission, and then moves through status tracking. It should not be described as if it works exactly like deposit or exactly like an immediate wallet exit.
14.4 Bucket-to-bucket movement
Bucket-to-bucket movement should be treated as real value movement between contexts, not as a hidden bookkeeping shortcut. In the current surface, transfer-between-buckets is a tracked funding flow with its own prepare step, transaction path, status checks, and finalization where required. That means operators should keep the source bucket, destination bucket, and resulting state legible enough that a user can tell where value started, where it moved, and whether the movement is complete.
This matters especially when an account-style bucket is being used to fund participation somewhere else. A user should not have to guess whether value is still sitting in the source bucket, already committed to the destination bucket, or still mid-lifecycle. Bucket-to-bucket movement is part of the user-facing funding story, not just a backend convenience.
15. Using Posts, Docs, Receipts, and Policy Well
Buckets need a record, not only a live participation surface. In the current model, these surfaces should be used deliberately rather than blended together. Use updates for movement over time. Use docs for reference material that should remain stable. Use receipts for concrete supporting records tied to execution, spending, vendor work, fulfillment, or other real follow-through. Use policy for the stable rules and expectations users should know before acting.
The operator should keep these surfaces cleanly separated. Do not use updates as policy. Do not use receipts as marketing. Do not hide durable rules in a rolling stream of updates. If the meaning of a path depends on something stable, that information belongs in policy or docs. A user should not have to reconstruct the meaning of a bucket by piecing together scattered posts after the fact. The stable reading surface should exist before participation begins.
This matters even more because policy is part of bucket readiness, not just later documentation hygiene. The current publish posture already depends on stable terms being present, and the broader operator standard is that a bucket should be understandable before participation, manageable while live, and checkable afterward. Posts and linked references are part of how that record stays legible over time.
16. Handling Mistakes, Disputes, and Corrections
Mistakes and disputes are part of live bucket operation. An offering may be described poorly. A request may be fulfilled incorrectly. A class may be configured with the wrong limit. A queue action may be delayed too long. A user may also dispute what a path meant, what state it is in, or what follow-through was actually promised. The first rule is to preserve legibility. Do not try to make the record cleaner by pretending the mistake or dispute never happened. Operators still own the human parts of the loop, and correction is part of that responsibility.
The second rule is to correct the live surface, not only the private conversation. If the bucket copy misled people, fix the public bucket surface. If a stable rule changed, update policy. If the issue affects how movement, follow-through, or evidence should be read, attach the relevant update, receipt, or proof openly enough that the bucket still makes sense afterward. A correction should improve the public record, not just the operator’s private explanation of it.
The third rule is to learn operationally. If one kind of mistake repeats, the problem is probably not one unlucky user. It is usually a weak configuration, a muddy offering frame, a weak queue habit, or an operator practice that should be changed before the next live path begins. A well-run bucket does not only recover from mistakes. It reduces the chance of repeating the same one.
17. Trust, Status, and Closeout
Trust in a bucket is built by legibility, not by hype. State what the bucket is for clearly. State what each offering is and is not. State whether fulfillment is immediate, pending, reviewed, delayed, or still waiting on queue progression. Keep queue state, receipt state, proof, and visible follow-through current enough that the public surface continues to mean what it says. A trustworthy bucket is not one that sounds certain. It is one that stays readable while live.
Operators should also understand the difference between chain truth and reflected platform state. The current stack includes onchain actions, offchain coordination, and indexed readability, and those layers do not always move in perfect lockstep. When the readable surface lags, the right answer is not to pretend the action did not happen and not to blur every issue into one vague sense that “something is wrong.” The right answer is to identify which layer is stale or delayed, reconcile the state, communicate it honestly, and keep the bucket usable while the readable surface catches up.
Status should therefore be described in practical categories rather than vague reassurance. A bucket surface may be current, delayed, stale, queue-backed, partially reflected, or waiting on operator action even when some underlying contract-backed facts are already real. Onchain truth is the strongest verification layer, but it is not the whole explanatory layer. The bucket page, request state, queue state, receipts, and proof are what make that truth readable in practice.
Closeout should answer the practical questions cleanly. What was offered. What was entered. What was fulfilled. What remains pending or had to be explained. What proof was posted. What receipts and policy record remain attached. What changed for next time. A bucket that cannot answer those questions cleanly was not really run to completion, even if some transactions happened successfully underneath it.
18. Operator Launch Checklist
Before opening a live path, the operator should be able to say yes to the following practical tests. This checklist is not separate from the rest of the manual. It is the compressed operating standard: the bucket should be understandable before participation, manageable while live, and checkable after the work is done.18.1 Before opening participation
The bucket purpose is clear. The mechanic matches the initiative. The public page tells the truth about what the path is, what is immediate, what is pending, and what still depends on review, queue handling, or later resolution. Stable policy and any supporting docs are in place. The collection layer is linked and ready. The class layer matches the user meaning. The offering mode, price, selection, fulfillment posture, and output pool are all explicit. Any request, earned, review, or craft logic has been tested end to end, including the real carrier and mint path where issuance is supposed to follow.
18.2 While the bucket is live
Pending work is actually being processed. Request rows are not being left in silence. Mint work is being monitored as execution work rather than assumed complete just because approval happened earlier. Reserved, captured, spent, and withdrawable states are being understood correctly. Users can tell what has resolved, what remains pending, and what still depends on queue progression or operator action. Updates are being posted when real movement happens. Receipts and proof are being attached when the initiative calls for them.
18.3 Before calling the path complete
Old pending rows have been resolved, rejected, or clearly explained. Issuance work has either completed or been openly accounted for. The bucket record contains the policy, docs, updates, receipts, and closeout evidence needed to make the initiative readable afterward. Closeout should be able to answer the practical questions cleanly: what was offered, what was entered, what was fulfilled, what remains pending or had to be explained, what proof was posted, and what changed for next time.
18.4 Preflight failure checks
Before opening any important path, run the failure checks that catch the most common trust-breaking mistakes in advance.
Collection linkage is real, ownership is where the mint path expects it, and the bucket is connected to the correct collection context.
Class controls, offering-level caps, output-level stock, and per-wallet limits do not conflict with each other.
Only the outputs meant to resolve are active, and weighted pools, selected outputs, labels, images, and metadata all match the live path. Valid resolution should come from the governed active output set, not from placeholder rows or stale output assumptions.
If craft inputs are involved, hold-versus-burn behavior has been tested, required approvals are understood, and the transformed result is readable afterward.
Queue approval is not being used as a substitute for actual fulfillability. If the carrier, stock, metadata, or mint path is not ready, the path is not ready. Approval and execution are connected, but they are not the same stage.
19. Closing Frame
A strong bucket is not only configured correctly. It is run correctly. The operator chooses the right mechanic, makes the participation path legible before launch, prepares the carrier layer before promising issuance, grants authority carefully, keeps request and mint work moving, handles payment and credit state honestly, uses policy, docs, updates, and receipts for the jobs they actually own, and closes the record in a way other people can still read afterward.
That is the practical standard. A bucket should be understandable before participation, manageable while live, and checkable after the work is done. If the bucket cannot still explain what was offered, what happened, what remains pending, and what proof or record supports the outcome, then it was not really run to completion.