Bucket Deposits and Bucket Credit

Buckets are one of the main pieces of Yokefellow.

A bucket is not just a page. It is the public surface where an initiative can explain what it is, what participation means, what rules apply, and what records should exist afterward.

Some buckets may accept YES deposits. What happens after deposit depends on how that bucket is configured.

The simple version is:

Captured deposit = the bucket receives the YES immediately
Bucket Credit = the user has bucket-linked credit that may be used later and may be withdrawable

This guide explains the difference.

Before you depositCopy link

Before depositing YES into a bucket, read the bucket page first.

Look for:

• what the bucket is for
• who operates it
• whether deposits are enabled
• whether deposits are captured immediately or held as Bucket Credit
• whether user withdrawals are available
• what the bucket mechanic is
• what participation may lead to
• what limits, conditions, or rules apply
• whether the bucket is active, preview-only, closed, or still being prepared

A deposit is not just a normal wallet transfer. It is participation in a specific Yokefellow surface.

Wallet balance versus bucket stateCopy link

Your wallet balance is the YES still sitting in your connected wallet.

Once YES is deposited into a bucket, it is no longer just wallet YES. It becomes part of that bucket’s state.

That bucket state may be handled in different ways.

Wallet YES = YES still in your wallet
Captured deposit = YES moved into the bucket immediately
Bucket Credit = YES credited to you inside that bucket

The bucket page should make the deposit posture clear before users act.

Captured depositsCopy link

Some buckets capture deposits immediately.

That means the YES goes directly into the bucket’s participation or funding surface when the deposit is made.

In this mode, the deposit is not treated like a user-held withdrawable balance. It is captured by the bucket according to that bucket’s stated purpose, mechanic, and rules.

Captured deposits fit buckets where the action is meant to immediately support or enter the bucket.

Examples may include:

• goal-based Splash buckets
• participation buckets where deposits count immediately
• campaign-style buckets
• buckets where the deposit itself is the entry action

For captured deposits, users should assume the deposit is committed unless the bucket terms say otherwise.

Bucket CreditCopy link

Some buckets may hold deposits as Bucket Credit.

Bucket Credit means the user has credit inside that specific bucket. That credit may be available for later actions inside that bucket, such as entering offerings or using bucket-linked participation paths.

Buckets that use Bucket Credit may also allow the user to withdraw unused available credit.

That is the key difference:

Captured deposit = committed to the bucket
Bucket Credit = user-linked bucket balance that may remain available

Bucket Credit is still bucket-specific. Credit in one bucket does not automatically become credit in every other bucket.

Withdrawable creditCopy link

Withdrawals apply only where the bucket is configured to hold user credit and allow withdrawals.

If a bucket captures deposits immediately, there may be no withdrawable user credit from that deposit.

If a bucket holds deposits as Bucket Credit, the user may be able to withdraw unused available credit, depending on the bucket’s rules and current state.

The practical rule is:

If the bucket captures deposits, treat the deposit as committed.
If the bucket gives Bucket Credit, check whether unused credit is withdrawable.

Public deposits may be disabledCopy link

Not every bucket accepts public deposits.

Some buckets are drafts. Some are concept previews. Some are private. Some may only be funded by the owner. Some may not be ready for participation yet.

If deposits are disabled, that usually means the bucket is not open for public deposits at that time.

That is not necessarily a bug. It may be the correct state for that bucket.

Bucket mechanics matterCopy link

Buckets can use different mechanics.

The current mechanic families are:

• Splash
• Leaky
• Manual

A Splash bucket is goal-based. It is built around a target or completion point.

A Leaky bucket is time-based. It is built around paced movement over time.

A Manual bucket is operator-directed. It gives the operator more control over timing and handling.

The mechanic can affect how deposits are used, but the mechanic alone is not enough. Always read the bucket’s deposit posture too.

Depositing does not mean every outcome is automaticCopy link

Depositing YES into a bucket does not always mean you instantly receive an NFT, prize, reward, right, or final result.

Some bucket activity may be immediate.

Some may depend on an offering.

Some may depend on review.

Some may depend on queue processing.

Some may depend on an operator completing a later step.

The bucket page and offering details should explain what the path actually does.

Bucket Credit and offeringsCopy link

Some buckets may have offerings.

An offering is a structured participation path inside a bucket. It may be a purchase path, earned path, request path, application path, grant path, or another configured path.

Bucket Credit may be used by a bucket or offering depending on how that surface is designed.

The important point is:

Deposit = value enters the bucket
Credit = user-linked value held inside the bucket when the bucket supports it
Offering = a structured path inside the bucket
Output = what the path may lead to

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

Fees and gasCopy link

Bucket deposits may include a Yokefellow platform fee.

Chain gas is separate.

That means a deposit can involve more than one cost layer:

Bucket deposit fee = Yokefellow platform fee
Network gas = Base network transaction cost

Gas is charged by the network, not by Yokefellow.

Always review your wallet confirmation before approving a transaction.

What to check after depositingCopy link

After a deposit, check:

• the transaction completed
• the wallet shows the expected change
• the bucket page reflects the deposit
• whether the deposit was captured or credited
• whether unused credit is available
• whether withdrawal is available for that bucket
• the activity record updates

Some app displays can take a little time to update after an onchain action.

A confirmed transaction and a refreshed platform view may not appear at the exact same second.

If something looks wrongCopy link

If something looks wrong after depositing, do not keep repeating the same action immediately.

First check:

• the wallet transaction
• the network
• the bucket page
• whether the page has refreshed
• whether the transaction is still pending
• whether the bucket accepts public deposits
• whether the bucket captures deposits or gives Bucket Credit
• whether the bucket is active or preview-only

If the transaction confirmed but the platform display has not updated yet, the readable app state may still be catching up.

Current guidesCopy link

Read Next:

• Getting Started with Yokefellow
• What is Yes?
• How to Add YES to Your Wallet
• What is a bucket?
• User Accounts and Yokefellow Market Basics
• NFT's, Rights, and Redemption
• Posts, Briefs, Updates, Policies, and Proof

More guides will be added as Yokefellow fills out.