How it works

Most activity on the site starts with a bucket. A bucket is a public surface around something trying to happen: a project, event, team, competition, creator path, sponsorship run, product launch, or some other effort that needs support and visibility.

A bucket is not just a place to collect funds. It gives people one place to understand what the effort is, why it matters, what support is for, and how progress will be shown in public.

Once a public surface exists, people can support it. Sometimes that support is simple. Sometimes it is the start of a longer relationship between the builder, the supporter, and whatever is being created.

The important part is that support is visible and structured instead of disappearing into a disconnected payment flow with no real surface around it.

Support means more when people can see what actually happened. That is where updates and proof come in. Builders can post progress, show milestones, attach receipts, document outcomes, and keep the public trail visible.

Some efforts only need a light proof trail. Others need a much deeper record. Yokefellow is built so proof can grow with the seriousness of the effort instead of forcing every case into the same template.

Builders can go beyond a simple support model. Depending on the use case, they may issue offerings, access, perks, sponsor placements, roles, claims, or other forms of participation tied to the effort.

In many cases, NFTs can be used as functional keys within that model. A key might unlock access, represent a right, mark participation, bind a permission, or carry a role into another surface. Not every builder has to use NFTs that way, but when they do, they are meant to be useful, not decorative.

A bucket does not have to be the end of the story. Yokefellow is being built so the same underlying primitives can support more than one site or one flow. A builder might begin with a public bucket, then later create connected experiences around events, teams, commerce, gated access, sponsorships, governance, or something else entirely.

This is where the SDK matters. It makes it possible to build on the same rails without rebuilding the whole system from scratch.

Yokefellow is not one fixed app flow. It is a set of reusable primitives.

Buckets provide public surfaces. Proof creates visible records. Offerings create structured participation. NFTs can act as keys when a builder wants them to carry access, rights, identity, roles, or permissions.

The SDK gives builders a way to use those primitives together or separately in custom apps. That means Yokefellow can support many kinds of products without pretending they all need to work the same way on the surface.

One app may lean heavily on buckets. Another may focus more on permissions or key-based access. Another may use the same rails in a way that barely resembles this site. That flexibility is part of the design.

Yokefellow gives people a way to:

• Create a public surface around something you want to make happen.
• Let others support it.
• Show what actually happened.
• Issue access, rights, or participation tied to that effort.
• Build further apps on the same rails instead of starting over.

That is the practical version. Underneath that, Yokefellow is being built as the engine behind a crypto app sphere, where builders can use shared primitives instead of starting from zero every time.