Yokefellow - Start Here
Risk Disclosures
Plain-English risk disclosures covering contracts, wallets, liquidity, lifecycle delays, indexing, operators, and platform control.
1. What This Document Is
This document is the plain-English risk notice for Yokefellow. Its purpose is to state the main risks clearly and directly so users, participants, operators, partners, and builders understand the boundary between what the platform can do and what it cannot guarantee.
This document is not the Whitepaper, not the Rights & Offerings paper, and not the Trust Boundaries and Platform Status paper. It is not meant to explain why Yokefellow matters or to map the full technical architecture. Its job is narrower: explain what can go wrong and what people should keep in mind before participating.
The tone here should stay simple and blunt. Short warnings are better than dense legal theater. If someone is deciding whether to use the platform, fund a bucket, enter an offering, receive an NFT-backed output, or rely on an operator-managed outcome, they should be able to understand the core risks without having to decode vague language. That is the role this paper owns in the launch set.
2. Smart Contract Risk
Yokefellow uses smart contracts for important parts of the system. That includes token movement, bucket-linked value movement, settlement-critical actions, and NFT collection or issuance relationships. Smart contracts can contain bugs, design flaws, integration mistakes, or unexpected behavior. If that happens, users may lose access to funds, lose expected functionality, see incorrect balance state, or experience parts of the platform behaving differently than intended.
Verification or review does not remove that risk. Verification makes deployed code easier to inspect. Review can reduce some kinds of error. Neither one guarantees that the system is free of bugs, exploits, or edge-case failures. Users should assume that contract risk exists whenever they interact with the onchain parts of the platform.
3. Wallet Risk
Using Yokefellow requires wallet-based interaction for important parts of the system. If a user loses access to their wallet, loses their keys, signs the wrong message, sends assets to the wrong address, uses a compromised device, or interacts with a malicious wallet surface, the platform may not be able to reverse the outcome. Wallet mistakes can result in permanent loss.
Users are responsible for the wallets and devices they use and for the signatures or transactions they approve. The platform cannot protect users from every phishing attempt, fake interface, compromised extension, or mistaken signature. This risk exists even if the Yokefellow app itself is functioning correctly.
4. Market and Liquidity Risk
YES participation and related activity can be affected by market conditions. Price can move quickly. Liquidity can be thin. Slippage can occur. Order execution may happen at an unfavorable time or may not happen at all under the conditions a user expected. A market can remain live while still behaving poorly for a user's intended action.
This matters because the platform includes a real economic layer rather than only static content. A user entering a bucket, moving YES, or participating through a priced path should understand that market behavior can affect participation cost, the speed of value movement, and how easily a position can be entered or exited. Market access does not guarantee good execution or stable pricing.
5. Pricing Variability
Some offerings may use pricing that changes over time rather than one permanently fixed amount. Even when a price is shown clearly at one moment, the amount required for participation may later differ depending on the offering design, the timing of the action, or the underlying YES pricing rule. That means the cost of participation may change even if the bucket and offering remain the same.
Users should read offering pricing carefully before participating. Operators should also understand that dynamic or market-linked pricing can create a different experience from fixed pricing. A user should not assume that the same offering will always cost the same amount unless the offering explicitly uses a fixed structure.
6. Transaction Lifecycle and Partial Completion Risk
Some Yokefellow actions are multi-step even when they look simple from one screen. A prepared action, a wallet signature, a submitted transaction, a confirmed transaction, and a fully reflected platform result are not always the same moment. Some flows may require status checks, later platform-side completion, or later synchronization before the result appears correctly across bucket, wallet, or activity surfaces.
That means a user may complete one valid step and still not yet have a fully finished result. A request can be accepted before the wallet step has happened. A transaction can confirm while the readable platform state is still catching up. In some flows, a transaction can be confirmed while business finalization is still pending. Users should not assume that one success message means every layer of the action is complete.
Users should also understand that blockchain actions may be difficult or impossible to reverse once submitted, confirmed, matched, or otherwise finalized through the relevant contract or platform flow. A partial, delayed, or misunderstood lifecycle is still a real risk.
7. Queue, Issuance, and Manual Review Delays
Not every offering resolves instantly. Some participation paths create pending request state. Some require manual review. Some depend on queue processing. Some are delayed by design. That means a user may complete their side of a flow and still not receive the final output immediately. This is not always a system failure. In many cases, it is the configured behavior of the offering.
Some issuance paths also depend on collection linkage, mint authority, collection ownership, stock, limits, metadata readiness, and queue execution being aligned correctly. A live offering is not, by itself, a guarantee that final issuance can complete immediately. Participation or approval state may still exist while final issuance is delayed, retried, or waiting on later operator or system action.
The risk is that resolution may take longer than the user expects, may remain pending for a meaningful period, or may depend on operator action that does not happen quickly. Users should not assume that participation means instant issuance unless the offering clearly says the path is immediate. Operators should not present review-, queue-, or issuance-dependent flows in a way that sounds instant when they are not.
8. Metadata, Indexing, and Display Limitations
NFT-backed outputs, offering surfaces, bucket pages, and related displays depend on metadata, indexing, and app-layer presentation. Metadata can be incomplete, delayed, stale, or misread by wallets and interfaces. NFT ownership may exist onchain even when a wallet does not display the asset automatically. Bucket pages, activity surfaces, and wallet-facing views may also lag behind the chain when indexing or app refresh is delayed.
This means visible display is not always the same as underlying chain truth. A user may need to verify a transaction, contract, or token directly rather than relying only on one app view or wallet surface. The platform aims to make state readable, but readability and freshness can still fail temporarily.
9. Third-Party Operator Risk
Many bucket outcomes depend on operators. Operators write offerings, define terms, review requests, run queues, post proof, upload receipts, and fulfill promises that are not fully reducible to contract enforcement. That means participants are exposed not only to platform risk but also to operator risk. An operator can describe an offering poorly, process requests slowly, fulfill badly, or fail to follow through on an initiative even if the underlying smart contracts and platform surfaces are working as intended.
This is one of the most important risks in the system. A bucket may be real. An NFT may be real. A transaction may be real. None of those facts automatically mean the operator fulfilled well, ran the initiative honestly, or handled disputes responsibly. Users should read the bucket, offering, and operator context carefully before participating.
10. Offchain Service and Sync Risk
Yokefellow is not only a set of contracts. It also depends on app surfaces, APIs, indexers, databases, queue processors, ownership sync, permission refresh, and other coordination layers. Those services can be delayed, degraded, stale, unavailable, or misaligned. If that happens, users may see incomplete activity history, delayed entitlement state, stale queue state, incorrect-looking bucket views, or permission effects that have not fully caught up to the underlying chain-backed facts.
That means a user may hold a relevant token onchain while bucket-facing access, entitlement views, or other dependent surfaces still appear wrong or incomplete. Offchain service issues can make the platform harder to use, harder to interpret, or temporarily misleading in presentation. Users should understand that app-level visibility problems do not always mean the same thing as onchain failure, but they are still real risks because they affect usability and trust.
11. Platform Control and Configuration Risk
Yokefellow should not be read as a system with no live control surfaces. Some parts of the platform still depend on configured roles, owner authority, recognized deployment paths, collection ownership, fee settings, environment alignment, and related platform-controlled settings. If those layers are changed, misconfigured, or misaligned, users may see degraded behavior, delayed functionality, or results that differ from expectation even when some underlying contracts remain valid.
Users and partners should therefore read the platform not only by asking whether a contract exists, but also by asking what control still exists in the live stack and whether the live app, indexer, and deployment environment are aligned correctly.
12. NFT and Rights Interpretation Risk
A user should not assume that every NFT-backed output means the same thing. Some outputs may grant access. Some may signal status. Some may preserve proof. Some may depend on bucket context, limits, expiration, operator review, or later fulfillment. A token can be real while its meaning remains narrow, conditional, or temporary.
This means users can misunderstand what they received if they look only at the NFT or only at the label without reading the offering structure and bucket context. The risk is expectation mismatch. A participant may read broad ownership, permanence, or unrestricted use into something that was actually designed as limited access, bucket-scoped utility, operator-defined permission, or a result that changes with lifecycle state.
13. No Guarantee Disclosures
Using Yokefellow does not guarantee profit, upside, access, successful fulfillment, operator performance, market liquidity, or uninterrupted platform continuity. Entering an offering does not automatically guarantee the broadest meaning a user might infer from it. Holding an NFT-backed output does not automatically guarantee platform ownership, financial return, unrestricted control, or permanent utility.
Users should assume that participation is structured, not guaranteed. Builders should assume that integration is real, not risk-free. Operators should assume that configuration and visibility can improve trust, but do not erase responsibility.
14. Jurisdiction and Use Restrictions
Depending on how the platform develops, some uses, offerings, or participation paths may be limited by law, regulation, policy, sanctions, platform rules, or operator constraints. Some users or operators may be restricted from certain forms of participation based on jurisdiction, legal status, or other compliance considerations. This document does not define those rules in full, but it makes one boundary clear: access to the platform or visibility of an offering does not automatically mean every person may lawfully participate in every way.
Users and operators are responsible for understanding the rules that apply to them. Additional platform terms or offering-specific restrictions may apply.
15. Practical Reading Rule
The safest way to approach Yokefellow participation is to read four things together:
the bucket, the offering, the output or NFT-backed result, and the fulfillment path.
Then read the risks alongside them. A bucket can be real and still depend on operator quality. A contract can be verified and still contain risk. An offering can be valuable and still be conditional. An NFT can be real and still be narrow in meaning. A visible app surface can be useful and still be stale, delayed, or partially synchronized. That is the honest way to read the platform.
16. Closing Frame
Yokefellow is designed to make participation more legible than vague alternatives. That does not make risk disappear. Smart contract risk exists. Wallet risk exists. Market and pricing risk exist. Transaction-lifecycle risk exists. Queue, issuance, and operator-delay risk exist. Metadata and display risk exist. Third-party operator risk exists. Offchain coordination and sync risk exist. Platform-control risk exists. Expectation-mismatch risk exists.