Proof-gated, not date-theater.
Yokefellow should only move a surface forward when the system can support it honestly. A feature can be important and still remain gated. A bucket can be designed and still remain closed. A governance structure can be drafted and still remain inactive.
Operating now
These surfaces are live enough for users, partners, and readers to inspect today. They are still part of an early system and should be read with the risk and trust documents beside them.
Yokefellow Identity Bucket
OperatingThe first active public bucket is live as a credit-backed identity surface: users can inspect its brief and policy, deposit withdrawable bucket credit, use offerings, collect critter ingredients, and craft limited profile identities.
Yokefellow web surface
OperatingThe public website, market surface, blog, trust pages, paper library, status page, stats page, and bucket surfaces are the current public front door for the platform.
Papers library
OperatingThe whitepaper, tokenomics, mechanics, rights, architecture, trust, builder, app, governance, and raise papers are available as public reference material.
YES on Base mainnet
OperatingYES is deployed on Base mainnet and acts as Yokefellow's native participation and economic rail.
Vault, settlement, and market rails
OperatingThe bucket custody layer, settlement layer, and YES/USDC market surface are live infrastructure that later buckets and apps can build around.
Indexer and readable activity
OperatingThe app reflects chain activity through indexed state so users can read balances, market movement, and platform history without reading raw events first.
Terms, privacy, risks, and trust boundaries
OperatingThe public trust layer explains legal terms, platform risks, privacy posture, onchain/offchain boundaries, control surfaces, and degraded states.
Being hardened
These are the near-term work lanes that make the public system safer, clearer, and easier to trust before more participation surfaces open.
Paper and site presentation
HardeningThe papers are being cleaned up for web reading so the public reference layer feels intentional instead of like raw document exports.
Identity Bucket credit loop
HardeningThe first public bucket now demonstrates withdrawable bucket credit, paid offerings, random ingredient outputs, burn-to-craft recipes, limited identity classes, and profile-facing NFT use.
Bucket publication discipline
HardeningPublic buckets should not open until their terms, support path, constraints, credit or capture behavior, proof plan, and operating responsibilities are clear.
Mainnet user-flow testing
HardeningDeposits, withdrawals, offering spends, craft burns, market actions, indexer reflection, fee display, wallet state, and explorer links need repeated checks from normal user wallets.
Contract and operational status surface
HardeningThe next status layer should show key live addresses, chain context, indexer freshness, known limitations, and what users should verify directly.
Legal and compliance review
HardeningPrize, raffle, charity, sale, proceeds, operator, money-transmission, and token-related surfaces should be reviewed before being presented as public participation paths.
Next bucket work
The first public bucket is live. The next bucket work should strengthen that proof, then expand only where the user purpose, terms, custody behavior, and operating record are clear.
Identity Bucket expansion
NextThe first bucket can expand with clearer public guides, more identity recipes, profile equip hardening, and user-visible records for how credit, offerings, and crafts behave in practice.
Founder and platform update bucket
NextA company-operated bucket can show updates, receipts, milestones, and platform work in the same structure Yokefellow expects others to use.
Project or proceeds bucket
NextA visible use-of-proceeds surface can show what a specific capital destination is for, what it funds, and what proof will be posted afterward.
Charity / leaky bucket
Review gatedCharity-style buckets remain a strong fit for Yokefellow, but they should wait for legal, accounting, operator, receipt, and charity-relationship review.
Random-prize or raffle-style bucket
Legal gatedPaid random-prize mechanics should not be treated as a normal bucket launch until the legal structure is confirmed. The Atlas should show that caution directly.
First-party app direction
First-party apps are how Yokefellow proves that the same bucket, offering, right, NFT, market, lifecycle, and proof rails can support multiple public experiences.
Auction House
Operating v1A first-party secondary-market surface for transferable Yokefellow-native NFT-backed outputs. Bids reserve Auction House bucket credit, accepted sales credit seller proceeds after the seller-paid 5% sale fee, and NFT transfer remains controlled while settlement hardens.
Lounge
PlannedA community and presence surface where identity, access, status, decor, and social permissions can become usable through recognized Yokefellow rights and metadata.
Dapp Maker
PlannedA builder app that helps turn bucket-connected ideas into real app structures using Yokefellow's SDK, API, lifecycle, wallet, and rights rails.
Reference app surface
ReframingThe current reference app proves the rails, but the public-facing game or app direction should be sharpened into something users understand immediately.
Builders, operators, governance, and infrastructure
The wider system should expand through controlled builder access, stronger operator habits, later governance, and long-term operating capacity rather than a sudden unstructured opening.
Controlled builder access
PlannedThe SDK and API are documented, but broader builder access should expand through controlled approval, proof, and operating standards instead of opening all at once.
Operator formation
PlannedYokefellow needs repeatable operator habits around bucket setup, offerings, collections, queues, receipts, finance review, dispute handling, and closeout.
Congress
LaterCongress is not active yet and should not be treated as decorative. It belongs later, when enough real governed structure exists to review standards, builders, buckets, proceeds, and platform expansion.
Yokefellow HQ
Long termHQ is a long-horizon operating base for engineering, infrastructure, content production, builder/operator formation, partner work, and demonstrations.
What the labels mean
Atlas uses status labels so the roadmap can stay honest without flattening every item into either live or imaginary.
Operating
Live enough for users to inspect or use now, while still subject to normal platform risk, sync delay, and improvement.
Hardening
Exists or is close enough to test, but still needs cleanup, monitoring, safer wording, legal review, or repeated mainnet checks.
Next
A near-term public direction that should follow after the basic site, status, and operating surfaces are clear.
Review gated
Promising, but should not open publicly until the relevant legal, operational, accounting, or technical review is complete.
Planned
Part of the intended Yokefellow expansion, but not represented as live functionality yet.
Later
A longer-horizon surface that should wait until there is enough real structure to govern, support, or operate honestly.
Read the papers behind the roadmap
Atlas is the short map. The papers explain the deeper structure: the thesis, mechanics, rights, trust boundaries, developer surface, first-party app direction, governance, and proceeds architecture.