What Is a Bucket?

A bucket is the core surface of Yokefellow.

It is where an initiative becomes readable, structured, and easier to follow. A bucket can explain what something is, who is operating it, how people can participate, what rules apply, what outputs may exist, what value has moved, and what proof should be posted afterward.

The shortest version is:

A bucket is a public participation surface.

But that sentence only gets us started.

A bucket is not only a page. It is not only a wallet. It is not only a fundraiser. It is the place where Yokefellow connects an idea, its terms, its participation paths, its operating mechanic, its records, and its outcomes.

The simple versionCopy link

A bucket gives an initiative one clear home.

That home can hold:

• the public explanation
• the current status
• the operator or responsible party
• the bucket mechanic
• deposit posture
• participation paths
• offerings
• rights
• NFTs or other outputs
• updates
• receipts
• proof
• closeout records

The point is to make participation easier to understand before users act and easier to verify after something happens.

Why buckets existCopy link

Most online participation is scattered.

A project might use one tool for payments, another for updates, another for access, another for proof, another for comments, and another for delivery. That makes it hard for users to know what was promised, what changed, what they received, and what actually happened.

Buckets exist to pull those pieces into one visible structure.

A bucket gives users a place to ask:

What is this?
Who is behind it?
How do I participate?
What happens if I do?
What proof will exist later?

That is the job of a bucket.

A bucket is more than a campaign pageCopy link

A normal campaign page usually explains a goal and asks for support.

A Yokefellow bucket can do more than that.

A bucket can connect the public explanation to actual platform behavior. It can have deposit rules, offerings, rights, NFTs, market-connected movement, operator updates, receipts, app links, and proof records.

That does not mean every bucket uses every feature.

It means the bucket is the container where those things can be organized.

A bucket is more than a walletCopy link

A wallet holds tokens.

A bucket gives tokens context.

That difference matters.

If YES moves into a wallet, the wallet can show that the tokens exist. But the wallet alone does not explain what the tokens were meant to support, what participation path they entered, what rules applied, or what proof should exist later.

A bucket helps attach meaning to activity.

Wallet = where tokens are held
Bucket = where participation is explained

Both matter, but they do different jobs.

Public buckets and personal bucketsCopy link

Yokefellow uses more than one kind of bucket surface.

A public bucket is tied to an initiative, project, app, campaign, offering surface, or public participation path.

A personal bucket is tied to a user account and helps support market activity, account-side balances, reserved orders, and personal platform state.

This post is mostly about public buckets.

For personal buckets and market balances, read:

• User Accounts and Yokefellow Market Basics

What a public bucket can be used forCopy link

A public bucket can support many different kinds of initiatives.

For example, a bucket could be used for:

• a project
• a product launch
• a giveaway
• a charity-style effort
• an app
• an event
• a creator initiative
• a competition
• a physical item or service
• a digital output
• a community program
• a future concept preview

The form can change. The bucket structure stays useful because it gives each initiative a readable place to define participation.

Bucket status mattersCopy link

Not every visible bucket is open for participation.

A bucket may be:

• draft
• preview-only
• active
• paused
• closed
• awaiting proof
• completed

This matters because a bucket can exist before it is ready to accept deposits or run offerings.

A concept-preview bucket, for example, may explain a future idea without accepting public deposits yet.

Users should check the bucket’s current status before acting.

Deposit posture mattersCopy link

Some buckets accept public deposits.

Some do not.

Some buckets capture deposits immediately.

Some hold deposits as Bucket Credit.

Some buckets may only be funded by the owner.

Some buckets may disable deposits while they are still being prepared.

The bucket should make this clear.

A user should not assume that every bucket deposit is withdrawable. A user should also not assume every bucket is active just because it has a public page.

For more detail, read:

• Bucket Deposits, Captured Deposits, and Bucket Credit

Bucket mechanicsCopy link

A bucket mechanic describes how a bucket behaves.

The current mechanic families are:

• Splash
• Leaky
• Manual

The mechanic is not just a label. It tells users and operators what kind of operating rhythm the bucket is built around.

A Splash bucket behaves differently from a Leaky bucket. A Manual bucket behaves differently from both. The mechanic helps set expectations for how value, timing, progress, and closeout should work.

Splash bucketsCopy link

A Splash bucket is goal-based.

It is built around a target, threshold, finish line, or completion point.

A Splash bucket usually makes sense when the initiative has a clear “done moment.”

Examples might include:

• raising toward a specific purchase
• funding a specific event
• reaching a prize target
• completing a campaign round
• funding a defined milestone
• running a goal-based concept bucket
• supporting a one-time launch or delivery

The basic shape is:

Open bucket
→ participation or deposits enter
→ progress moves toward a target
→ target is reached or close condition happens
→ bucket moves toward selection, fulfillment, proof, or closeout

The important idea is that a Splash bucket is not meant to leak forever. It is built around reaching a visible point.

What Splash should make clearCopy link

A strong Splash bucket should explain:

• what the target is
• what counts as completion
• whether deposits are captured or credited
• whether participation creates entries, rights, claims, or another output
• what happens when the target is reached
• whether there is selection, redemption, fulfillment, or closeout
• what proof should be posted afterward
• what happens if the target is not reached
• whether another round may begin later

Splash works best when the finish line is easy to understand.

If the target is vague, the bucket becomes hard to trust.

Splash and target completionCopy link

Target completion should be more than a vibe.

A Splash bucket should make it clear whether the target is based on:

• YES deposited
• USDC raised
• market conversion
• number of participants
• number of entries
• another measurable condition

Different Splash buckets can use different completion logic, but the bucket should explain which one applies.

For example, a goal-based bucket may accept YES but track whether enough USDC has actually been raised after market activity. Another bucket may count entries. Another may track a fixed participation cap.

The user should not have to guess what “complete” means.

Splash and closeoutCopy link

A Splash bucket needs a closeout posture.

Closeout is the record that explains what happened after the bucket reached its target or ended.

Closeout may include:

• final status
• winner or selection result
• payout or fulfillment record
• receipts
• redemption steps
• NFT issuance
• proof links
• what remains pending
• whether a next round will open

A Splash bucket is strongest when users can see the full path:

Target
→ completion
→ outcome
→ proof
→ closeout

That is what separates a structured bucket from a vague campaign.

Leaky bucketsCopy link

A Leaky bucket is time-based.

Instead of one clean finish line, a Leaky bucket is built around paced movement over time.

A Leaky bucket can be useful when an initiative should run continuously or in recurring cycles rather than closing all at once.

Examples might include:

• ongoing support programs
• recurring charity-style routing
• long-running seasons
• community support flows
• creator or project support
• scheduled conversion of YES into USDC
• gradual funding movement over time

The basic shape is:

Open bucket
→ value enters
→ bucket follows a schedule
→ a defined amount or percentage moves on each tick
→ updates, receipts, and proof keep the flow readable

The important idea is that Leaky is not about one big completion moment. It is about controlled throughput.

What Leaky should make clearCopy link

A strong Leaky bucket should explain:

• what the bucket is supporting
• what value enters the bucket
• what value moves out
• how often the leak happens
• whether the leak is a percentage or fixed amount
• whether the leak rate changes by tier or condition
• what pauses or stops the leak
• who controls the schedule
• what receipts or proof will be posted
• what happens if market liquidity is thin
• what closeout or reporting exists over time

Leaky buckets need pacing rules.

Without pacing rules, a Leaky bucket becomes hard to follow.

Leaky and market movementCopy link

Some Leaky buckets may sell YES into the market over time.

That does not mean the bucket should ignore liquidity.

A serious Leaky bucket should care about market conditions, available bids, slippage, timing, and whether the movement is healthy for the bucket’s purpose.

A simple Leaky rule might say:

Every period, sell a defined percentage of available YES.

A stronger Leaky rule might also account for:

• available market liquidity
• maximum sell amount
• minimum acceptable execution
• pauses during poor liquidity
• tiered leak rates
• operator review
• receipts after completed movement

The point is not only to move value. The point is to move value in a way the public can understand.

Leaky and public trustCopy link

Leaky buckets should be especially clear about reporting.

Because they may run for a long time, users need to understand where value is going and how proof will appear.

A good Leaky bucket may use:

• periodic updates
• receipt posts
• transaction links
• donation records
• payout records
• closeout summaries
• ongoing status notes

The bucket should not ask users to trust a recurring flow that never explains itself.

Manual bucketsCopy link

A Manual bucket is operator-directed.

It is used when the bucket needs flexibility instead of an automatic target completion path or a fixed leak schedule.

Manual buckets can fit cases where timing, fulfillment, review, or movement depends on operator judgment.

Examples might include:

• irregular project funding
• experimental initiatives
• manual review campaigns
• operator-controlled programs
• one-off participation paths
• buckets where movement should not happen on a fixed schedule
• buckets that need more human decision-making

The basic shape is:

Open bucket
→ participation or value enters
→ operator reviews or acts when appropriate
→ updates, receipts, and proof explain what happened

Manual does not mean vague.

Manual means the operator carries more responsibility for keeping the bucket clear.

What Manual should make clearCopy link

A strong Manual bucket should explain:

• who operates it
• what the operator can do
• what users can expect
• when updates should appear
• whether deposits are captured or credited
• whether offerings are immediate or reviewed
• what proof will exist
• what conditions trigger operator action
• how closeout will be handled

Manual buckets can be useful, but they need discipline.

The less automatic the mechanic is, the more important the public record becomes.

Choosing the right mechanicCopy link

The mechanic should match the initiative.

Use Splash when the bucket has a meaningful finish line.

Use Leaky when the bucket is meant to move value over time.

Use Manual when operator judgment and flexible timing matter more than automatic behavior.

Splash = goal-based
Leaky = time-based
Manual = operator-directed

A bucket becomes confusing when the mechanic does not match the real thing being operated.

A one-time prize bucket should usually not act like an endless Leaky bucket.

An ongoing support program may not fit a one-time Splash structure.

A complex review-based initiative may need Manual behavior.

The mechanic is part of the promise the bucket is making.

Offerings inside bucketsCopy link

A bucket can contain offerings.

An offering is a structured participation path.

An offering may be:

• a purchase path
• an earned path
• a request path
• an application path
• a grant path
• another configured path

The bucket explains the larger initiative. The offering explains the specific way a user can participate.

Bucket = the public surface
Offering = the path inside the bucket
Output = what the path may lead to

Those pieces are related, but they are not the same thing.

NFTs and rights inside bucketsCopy link

A bucket may issue or connect to NFTs, rights, claims, access, proof, or other outputs.

The NFT is often the carrier.

The right is what the user may actually receive, use, access, prove, or redeem.

The bucket matters because it gives those rights context.

For example, an NFT from one bucket may mean proof of participation. Another NFT may mean access. Another may be redeemable. Another may be a role or permission. Another may only be a display object.

Users should read the bucket and offering before assuming what an NFT means.

For more detail, read:

• NFTs, Rights, and Redemption

Apps and surfaces can use bucketsCopy link

A bucket does not have to live only as one public page.

Apps and other surfaces can build on bucket structure.

That is one of the important parts of Yokefellow.

An app can use a bucket as its anchor, then build a more specific user experience around it.

For example, a game app might use a bucket to hold its public context, offerings, player outputs, and NFT issuance. A market surface might use personal buckets to support account-side balances and reserved orders. A community app might use bucket-linked rights to decide who can enter a space, display an item, or hold a role.

The app can have its own interface, but the bucket gives it structure.

What an app can read from a bucketCopy link

A bucket-connected app may use bucket state to understand things like:

• what bucket the app belongs to
• what the bucket is called
• what participation paths exist
• what offerings are available
• what user wallet is connected
• what outputs or rights the user holds
• what funding or credit state exists
• what requests are pending
• what queue work remains
• what activity has happened

That allows the app to show a specialized experience without inventing a separate system from scratch.

What an app can write through a bucketCopy link

Depending on how the app is built, a bucket-connected app may help users:

• enter an offering
• buy an output
• request access
• submit an earned action
• craft or upgrade an output
• deposit into a bucket
• withdraw where allowed
• trigger issuance
• read queue state
• confirm lifecycle state
• display proof or receipts

The app does not need to replace the bucket. It can use the bucket as the record and control surface behind the app experience.

Why bucket-connected apps matterCopy link

Bucket-connected apps matter because Yokefellow is not meant to be one static website.

Different apps can create different experiences while still using the same underlying primitives.

The same bucket model can support:

• games
• auctions
• community spaces
• creator tools
• fundraising surfaces
• contests
• access systems
• redemption flows
• builder tools
• physical or digital product claims

That means Yokefellow can expand without every app inventing its own separate account model, funding model, rights model, and proof model.

The bucket gives the app a shared foundation.

Apps do not erase bucket rulesCopy link

An app can make a bucket easier to use, but it should not erase the bucket’s rules.

If the bucket says a right is limited, the app should respect that limit.

If an offering is request-based, the app should not make it look instant.

If an output is not transferable, the app should not present it like a normal tradable item.

If a deposit is captured, the app should not imply it is withdrawable credit.

The app experience should make the bucket clearer, not less honest.

Buckets and proofCopy link

A bucket should help preserve the record of what happened.

That record may include:

• posts
• briefs
• updates
• activity
• transaction records
• receipts
• NFT mint records
• redemption records
• proof
• closeout posts

This matters because participation should not disappear into private explanation.

If a bucket raises toward something, issues something, redeems something, or completes something, the public record should help users understand the result.

For more detail, read:

• Posts, Briefs, Updates, Policies, and Proof

Why buckets are central to YokefellowCopy link

Yokefellow is not only trying to move tokens.

It is trying to make participation structured.

The bucket is the center of that structure because it keeps the important pieces together:

Purpose
→ terms
→ participation
→ funding or credit
→ offerings
→ NFTs or rights
→ app surfaces
→ redemption
→ proof
→ closeout

Not every bucket uses every step, but the model gives initiatives a stronger way to organize what they are asking users to do.

How users should read a bucketCopy link

Before participating in a bucket, check:

• what the bucket is for
• who operates it
• whether it is active or only a preview
• whether deposits are enabled
• whether deposits are captured or credited
• what mechanic it uses
• what offerings are available
• what rights or NFTs may exist
• whether an app or surface is connected to it
• what redemption requires
• what policy or limits apply
• what proof or receipts should exist later

If those pieces are not clear, slow down before acting.

What a bucket does not guaranteeCopy link

A bucket can make participation clearer, but it does not remove every risk.

A bucket does not automatically guarantee:

• a successful outcome
• instant fulfillment
• permanent access
• deep market liquidity
• operator performance
• that every NFT is transferable
• that every deposit is withdrawable
• that every visible concept is active
• that every connected app supports every possible bucket feature

The bucket is the structure users should read. The actual meaning still depends on the bucket’s status, rules, offering details, operator actions, app behavior, and platform records.

A good bucket should answer the basic questionsCopy link

A strong bucket should help users understand:

What is this?
Who is responsible?
What can I do here?
How does this bucket behave?
What happens if I participate?
What are the limits?
What app or surface uses this bucket?
What proof will exist later?

That is the standard.

The bucket does not need to be complicated. It needs to be legible.

Read deeper hereCopy link

Bucket Mechanics Rights and Offerings Roadmap/Atlas Current Status

Current guidesCopy link

Start here:

• Getting Started with Yokefellow
• What is Yes?
• How to Add YES to Your Wallet
• Bucket Deposits, Captured Deposits, and Bucket Credit
• User Accounts and Yokefellow Market Basics
• NFTs, Rights, and Redemption
• Posts, Briefs, Updates, Policies, and Proof

More guides will be added as Yokefellow fills out.