Posts, Briefs, Updates, Policies, and Proof

Posts, Briefs, Updates, Policies, and Proof

Yokefellow is not only a place where users click buttons.

It is also a place where buckets, offerings, rights, deposits, redemptions, updates, receipts, and outcomes should leave a readable public record.

This guide explains how to read that record.

The simple versionCopy link

Yokefellow uses posts and records to explain what a bucket is, what users should expect, what changed over time, and what proof exists after something happens.

Brief = the main explanation
Update = something changed or progressed
Policy = the stable rules or conditions
Receipt = evidence of a completed action
Proof = the record that helps users verify what happened

Not every bucket will have every type of record right away, but the goal is to make important participation easier to understand before and after users act.

Why posts matterCopy link

Posts help keep a bucket understandable.

A bucket page may explain the core idea, but a bucket can also need supporting posts that explain details, changes, rules, progress, proof, or closeout.

That matters because participation should not depend on private explanation.

Users should be able to read the public surface and understand:

• what the bucket is
• what the bucket is trying to do
• what participation means
• what rules apply
• what has changed
• what proof exists afterward

The public record makes the bucket easier to trust and easier to review.

What a brief isCopy link

A brief is the main explanation for a bucket, guide, initiative, or concept.

For a bucket, the brief should usually answer the biggest questions:

• what this bucket is
• why it exists
• who operates it
• what mechanic it uses
• what users can do
• what users should not assume
• what the current status is
• what rules or limits matter

A brief should not be vague hype. It should help the user understand the bucket before acting.

Bucket brief versus normal postCopy link

A bucket may have many posts, but usually only one main brief.

The main brief is the clearest “read this first” document for that bucket.

A normal post can explain a smaller update, a progress item, a policy note, a receipt, a launch note, or another supporting detail.

Bucket brief = main explanation
Normal post = supporting record or update

This is why a bucket may have a “Read the brief” link and also have other related posts.

What an update isCopy link

An update explains something that changed or moved forward.

An update might explain:

• a bucket status change
• a new offering
• a funding milestone
• a rule clarification
• a new receipt
• a technical change
• an operator decision
• a closeout step
• a paused or disabled feature

Updates are useful because buckets can move over time.

A good update should make the current state easier to understand, not harder.

What a policy isCopy link

A policy is a stable rule surface.

A policy should explain the rules, limits, conditions, eligibility, review path, redemption path, or operating standards that apply to a bucket or offering.

Policies matter because users should not have to guess what the rules are.

A policy may explain things like:

• who can participate
• what is allowed
• what is not allowed
• what counts as completion
• what happens if something fails
• what redemption requires
• what limits apply
• what review or approval means
• what the operator is responsible for

A policy should be more stable than a normal update.

What a receipt isCopy link

A receipt is a record that something happened.

A receipt may show that funds moved, an expense was paid, a prize was delivered, a donation was made, an output was issued, or another action was completed.

A receipt should help users connect a claim to evidence.

Examples may include:

• transaction links
• payment records
• delivery records
• fulfillment notes
• posted proof
• closeout summaries
• operator records

A receipt does not need to explain the whole bucket. Its job is to support a specific action or result.

What proof meansCopy link

Proof is the evidence trail that helps users verify what happened.

On Yokefellow, proof can come from different layers.

Some proof may be onchain.

Some proof may be offchain.

Some proof may be posted by an operator.

Some proof may come from the platform’s activity record.

Examples include:

• wallet transactions
• token transfers
• bucket activity
• market activity
• NFT mint records
• post history
• receipts
• redemption records
• closeout posts
• operator-provided evidence

The strongest proof depends on what question the user is asking.

Onchain proof and platform recordsCopy link

Onchain proof is useful when the question is whether a blockchain action happened.

For example:

• Did a transaction confirm?
• Did tokens move?
• Was an NFT minted?
• Was an NFT transferred?
• Did a market action settle onchain?

Platform records are useful when the question is what that action meant inside Yokefellow.

For example:

• Which bucket did this belong to?
• What offering was involved?
• What was the user trying to enter?
• What was the operator supposed to fulfill?
• What receipt or closeout record explains the result?

Both layers matter.

Onchain proof = what happened at the contract or transaction layer
Platform record = what that action means inside Yokefellow

Why proof is not only one linkCopy link

A single transaction link can prove that something happened onchain.

It may not explain the whole user-facing meaning.

For example, a transaction may show that an NFT was minted. The bucket and offering explain what that NFT is supposed to mean.

A receipt may show that something was delivered. The policy explains what delivery was supposed to require.

A closeout post may explain how a bucket ended. The activity record may show the steps that happened before closeout.

That is why Yokefellow uses a record stack instead of only one kind of proof.

How to read a bucket recordCopy link

When reviewing a bucket, start with the most stable information first.

A practical reading order is:

1. Read the bucket page.
2. Read the bucket brief.
3. Check whether deposits or participation are enabled.
4. Read the offering details if you are entering a path.
5. Check policy or rules if the path has conditions.
6. Review recent updates.
7. Look for receipts or proof if the bucket claims something happened.
8. Check activity records where available.

This order helps separate the main explanation from later changes.

Draft, preview, active, and closed statesCopy link

Not every visible bucket is ready for participation.

A bucket may be:

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

This matters because a post may describe a future concept, a live path, or a completed record.

Users should not assume a bucket is active just because a post exists.

The bucket page should make the current state clear.

Related postsCopy link

A bucket can have more than one related post.

For example, one bucket may have:

• one main brief
• several updates
• a policy post
• a proof post
• a closeout post

Those posts work together.

The brief explains the bucket. Updates explain changes. Policies explain rules. Receipts and proof explain what happened.

What users should check before actingCopy link

Before participating in a bucket or offering, check:

• the bucket status
• the main brief
• whether participation is enabled
• whether deposits are captured or credited
• whether the offering is immediate or delayed
• whether the path depends on review
• whether redemption has conditions
• whether an NFT or right has limits
• whether the policy is clear
• whether proof or receipts are expected later

If the public record does not explain the path clearly enough, the user should slow down before acting.

What operators should keep clearCopy link

Operators should use posts carefully.

A good operator should keep these things separate:

• the main bucket explanation
• later updates
• stable policy
• receipts
• proof
• corrections
• closeout

Mixing all of those into one vague post can make a bucket harder to understand.

The public record should help users follow the bucket without needing private explanation.

Corrections and changesCopy link

Sometimes a bucket may need a correction.

A correction should be clear about what changed.

For example:

• an old statement was wrong
• a rule was clarified
• a status changed
• an expected step was delayed
• a receipt was added
• an offering was paused
• a proof link was corrected

A correction is not automatically bad. It is better to correct the public record than to leave users guessing.

CloseoutCopy link

Closeout is the record that explains how a bucket, round, offering, or campaign ended.

A closeout may explain:

• what happened
• what was delivered
• what was not delivered
• what funds moved
• what proof exists
• what receipts were posted
• what remains pending
• what comes next

Closeout matters because participation should not disappear after the action.

A good closeout helps users understand the final state.

Current guidesCopy link

Start here:

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

More guides will be added as Yokefellow fills out.