SNJUAbstract
Artificial intelligence is becoming a basic production capability. Training, inference, evaluation, and agent execution all depend on compute, yet access to capable infrastructure remains uneven. Much of the available capacity is controlled by a small number of centralized operators, while independent hardware owners often lack a practical way to make idle or specialized resources discoverable for serious workloads. SNJU proposes a coordination protocol for this gap. Its purpose is not to replace every cloud provider or make every workload portable by default. Its purpose is to create a common layer through which independent capacity, application builders, and community participants can express demand, evaluate compatibility, record execution, and settle responsibilities under shared rules.
The SNJU design begins with a simple premise: decentralized compute is not created merely by listing machines. A useful network must coordinate heterogeneous hardware, make task conditions legible, preserve evidence about what occurred, and provide a process for resolving disagreement. It must also respect the fact that AI workloads differ widely. An inference request may need proximity and predictable response time. A training job may need a longer reservation, storage affinity, and reproducible runtime images. An evaluation job may need strict isolation and an inspectable artifact trail. The protocol therefore treats workloads as structured commitments rather than anonymous units of capacity.
SNJU is an independent token and protocol brand. In the proposed system, the token has a functional role in coordination, verification, and governance. This paper does not describe it as a financial instrument and does not define market terms. The paper instead focuses on the protocol questions that determine whether a decentralized AI compute network can earn durable participation: what information a task should carry, how a provider can represent capability, which receipts should survive execution, how challenges can be handled, and how a community can evolve standards without fragmenting the network.
1. Context: the compute coordination problem
AI infrastructure is often discussed as if capacity were one interchangeable commodity. In practice, the usefulness of compute depends on hardware type, memory topology, networking, locality, software environment, availability window, security posture, and the operational care of the person running it. Centralized platforms solve much of this by owning or tightly managing the environment. Their model is effective for many users, but it can also concentrate access, create opaque scheduling decisions, and leave independently owned capacity outside the workflows where it could be useful.
A decentralized alternative faces a different set of constraints. The network cannot assume that operators are identical, that workloads can be moved without friction, or that every execution result is self-evident. A robust protocol must model diversity instead of hiding it. It needs a vocabulary for the properties that matter to a requester, a way for providers to make bounded representations about their machines, and an execution record that can be examined when a result is disputed. It must be open enough to include new participants while retaining safeguards against fabricated capabilities, unreliable scheduling, and malicious workloads.
The coordination problem is therefore social and technical at the same time. Builders want reliable execution without spending hours negotiating every job. Providers want a clear path to participate without exposing unnecessary operational detail. Reviewers and governors need enough visibility to assess process integrity without becoming a centralized approval desk. SNJU is designed around these tensions. Its proposed architecture favors explicit commitments, modular policy, and evidence that can be audited at the level appropriate to the workload.
2. Thesis: compute as a shared protocol resource
SNJU treats AI compute as a resource that should be discoverable and governable across organizational boundaries. This does not require a single global scheduler with unrestricted authority. Instead, it requires shared interfaces through which participants can communicate what they need, what they can provide, and what they can prove after a task completes. The protocol acts as a coordination layer between application-level demand and operator-level supply.
Three principles shape this thesis. First, participation should be open in the sense that a capable operator can enter through known requirements rather than private relationships. Second, the network should favor verifiable work over unverifiable claims. A provider does not need to reveal every internal detail, but the network needs durable receipts about task acceptance, environment assumptions, execution milestones, and delivered artifacts. Third, governance should be connected to actual protocol stewardship. Parameters, standards, and challenge processes should be changeable through transparent procedures rather than by a permanent private administrator.
This approach does not assume that decentralization is valuable in every dimension. Some workloads will continue to require dedicated infrastructure, private environments, or contractual arrangements outside a shared network. The proposed protocol is useful where coordination benefits from broader access to capacity and where the parties can express enough structure to make execution accountable. SNJU therefore focuses on a spectrum of workloads, from public inference services to controlled evaluation runs, rather than claiming to be a universal substitute for every form of compute procurement.
3. Proposed architecture
The SNJU architecture is organized as cooperating layers. The layers are conceptually separate so that improvements to one area do not require rewriting the entire protocol. A workload specification layer describes what a requester wants to run. A discovery layer lets providers advertise compatible capability under bounded, inspectable metadata. A coordination layer matches proposals and records task state. An execution evidence layer collects receipts. A verification and governance layer handles review, disputes, and evolving standards. Implementations may combine these layers differently, but keeping their responsibilities clear makes the protocol easier to reason about.
Workload specification
A workload specification is a structured description of the task, not simply a hardware request. It can include the class of work, required runtime image or dependency set, resource envelope, input handling expectations, output artifact format, deadline logic, and the level of evidence the requester expects. The protocol should allow simple specifications for low-risk inference while supporting richer commitments for longer or more sensitive work. Specifications should be versioned so that a provider and a requester can agree on the meaning of a field at the time a task is accepted.
Capability discovery
Provider records express capabilities in a way that is useful for matching but does not force operators to expose private infrastructure topology. A record may describe hardware class, memory class, supported runtime environments, geographic or jurisdictional constraints when voluntarily supplied, availability windows, and declared execution policy. The design should support attestations where possible, yet avoid treating any single attestation method as universally sufficient. Different workloads will require different levels of confidence.
Coordination state
The coordination layer tracks a task from intent through completion or exception. State transitions should be explicit: a request is published, a proposal is selected, an environment is prepared, execution begins, receipts arrive, and the task is closed or challenged. This state model makes it easier for participants to understand what obligations are active at a given moment. It also creates a stable basis for user interfaces, developer integrations, and later governance review.
Interface versioning and interoperability
Interoperability depends on more than a shared name for a task. A field that appears stable can have different consequences across software versions, hardware families, and execution environments. SNJU therefore proposes that workload specifications, capability records, and receipt schemas carry explicit version references. A provider should be able to say which version it understands before accepting a task, and a requester should be able to preserve the version that governed an execution after the software around it has changed. This gives builders a path to evolve integrations without requiring all network participants to upgrade at the same instant.
Versioning is also a practical governance tool. It lets the community introduce a more precise evidence field or a safer runtime standard while maintaining a documented transition path for older integrations. Deprecation should be visible, time-bounded, and justified by a clear reason such as security, ambiguity, or an incompatible definition. The goal is not perpetual backward compatibility. It is to avoid a network where operators discover that their participation status changed because a specification moved without notice.
4. Workload classes and execution paths
AI compute is not one workflow. SNJU distinguishes workload classes because each calls for different scheduling and verification expectations. The protocol should begin with a limited set of comprehensible paths rather than imply that every machine can safely execute every job. Clear boundaries make a network more legible to both builders and operators.
Inference
Inference tasks typically value fast routing, compatible runtime environments, and predictable handling of requests. A proposed inference path can describe a model interface, expected resource bounds, response handling requirements, and an execution receipt format that preserves task-level accountability without retaining sensitive application payloads by default. The goal is to help builders discover usable capacity while giving providers clear conditions for participation.
Training and fine-tuning
Training-oriented work is usually longer running and more operationally demanding. A task may need a defined storage relationship, checkpoint behavior, a reproducible environment, and explicit rules for interruption or recovery. SNJU does not assume that training data should be sent to an arbitrary operator. Instead, the protocol model can allow requesters to specify isolation, encrypted transfer, locality, or trusted execution requirements where those are available. A provider can then opt into only the task classes it can responsibly support.
Evaluation and benchmarking
Evaluation tasks benefit from a strong artifact trail. A requester may want to compare a model run against a declared dataset version, harness version, and environment configuration. The protocol can represent this as an evaluation bundle whose expected outputs and receipt requirements are defined before execution. The value is not a magical guarantee of correctness. The value is a clearer record that lets participants inspect how a result was produced and whether it conforms to the requested procedure.
5. Provider participation and operational responsibility
Operators are central to the network because they supply the physical systems on which work occurs. Their participation should be governed by understandable expectations rather than vague promises. A provider joins by presenting a capability record, choosing the workload classes it accepts, and adhering to the evidence requirements associated with those classes. The protocol can support reputation inputs over time, but a reputation system should not become an opaque score that hides the reasons behind a decision. Operators need a path to understand, contest, and improve the signals associated with their participation.
Provider responsibility begins before execution. An operator should be able to state the conditions under which it will accept work, including supported runtimes, maintenance windows, resource limits, and data handling boundaries. At acceptance, the provider and requester should share a stable view of the task specification. During execution, the provider is responsible for producing the receipts required by the agreed path. If conditions materially change, the state model should make that visible instead of allowing the task to silently drift from its original assumptions.
The protocol should also make room for operator autonomy. Providers may decline task classes, enforce local policy, or participate through a cooperative service layer. Decentralization does not mean forcing every participant into identical operations. It means creating a common set of rules that lets diverse operations interoperate while preserving accountability at the task boundary.
6. Verification, receipts, and challenges
Verification is the difference between a directory of machines and a coordination protocol. SNJU proposes that tasks produce evidence proportionate to their risk. For a simple workload, a receipt may record acceptance, environment identity, start and completion markers, and an output commitment. For a higher-assurance path, evidence may include signed logs, reproducibility references, sampled checks, attestations, or reviewable artifacts. The protocol should avoid demanding maximum disclosure for every task because that would harm usability and privacy. Instead, it should make the evidence expectation explicit before work begins.
A receipt is not the same as proof of every property a requester may care about. It is a durable claim about a process step, expressed in a format that another participant can inspect. This distinction matters. The network should be honest about the limits of automated verification, especially for complex model behavior or sensitive data environments. When automated checks cannot resolve a dispute, a challenge process provides a defined route for escalating the issue.
Challenges should be bounded, evidence-led, and resistant to harassment. A claimant should identify the relevant task, state the alleged deviation, and provide the basis for review. The process can define time windows, evidence requirements, and resolution pathways without implying that every disagreement can be decided by a single automated rule. Governance bodies or designated review mechanisms may handle difficult cases, with published procedures that make decisions legible to the broader community.
Evidence tiers
Not all work needs the same receipt depth. SNJU can define evidence tiers that a requester selects when creating a task. A baseline tier may preserve task acceptance, declared environment references, completion status, and an output commitment. A stronger tier may require signed runtime events, artifact manifests, or independent replay inputs. A specialized tier may combine remote attestation, restricted execution conditions, or sampled third-party review when the technology and the workload justify those measures. The important point is that the tier is chosen before execution, so a provider understands the burden and a requester understands the limits of the resulting record.
Evidence tiers should not turn into a false hierarchy where every high-tier receipt is assumed to be better for every use case. A lightweight inference request may be safer and more usable with narrow data collection than with a broad logging requirement. Conversely, a benchmark intended for public comparison may need a richer artifact trail. Governance should periodically review whether a tier's requirements still correspond to the risk it was created to address. This keeps verification tied to the purpose of the work rather than to a static checklist.
7. SNJU token utility
The SNJU token is proposed as a unit of protocol utility. Its role is connected to the actions that keep a decentralized compute coordination system coherent: participating in certain coordination flows, supporting verification and challenge processes, and contributing to governance. This functional framing is deliberate. A protocol token should be evaluated by whether it helps participants express commitments and steward shared infrastructure, not by speculative language detached from network use.
In coordination, SNJU may be used where a common protocol unit is needed to express task-related commitments or access defined network actions. In verification, it may support processes that discourage careless or adversarial claims and that give review mechanisms a clearly bounded basis for participation. In governance, it can represent a route through which eligible participants propose, discuss, and decide on changes to protocol parameters and standards. Exact mechanisms remain subject to technical review and community design.
Token utility does not remove the need for good product design. Builders should not need to understand every governance detail to submit a clearly specified task. Operators should not need to navigate ambiguous rules to declare their capabilities. The protocol should use its common unit where it adds accountability or shared coordination, while keeping user-facing workflows comprehensible and proportionate to the task at hand.
8. Governance and protocol evolution
A compute coordination protocol cannot remain static. Hardware changes, AI software evolves, new workload classes emerge, and security practices mature. Governance is the process by which SNJU can adapt without allowing a small group to silently redefine network rules. The proposed approach separates routine operational parameters from changes that materially alter participant rights or protocol scope. This distinction helps the community choose an appropriate level of deliberation for each decision.
Governance should begin with clear proposals. A proposal describes the problem, the intended change, the affected interfaces, expected tradeoffs, and how success or failure will be evaluated. Technical discussions should be accessible to operators and builders, not only to specialists. When a change affects evidence requirements, for example, the proposal should explain the additional operational burden as well as the expected increase in confidence. When a change affects workload categories, it should explain how compatibility and safety boundaries will evolve.
Delegation may be useful for participants who want informed representation without personally reviewing every technical update. However, delegation should remain visible and revocable. Working groups can also provide depth in areas such as security, runtime standards, or operator experience. Their role is to develop and publish analysis, not to replace the community's ability to inspect a decision path. Transparent governance does not guarantee universal agreement. It creates a record of how disagreement was handled and how a rule came into force.
Upgrade discipline
Protocol upgrades should be treated as operational events, not only as voting outcomes. A proposed change needs a migration note that identifies affected task fields, provider records, receipt parsers, and client interfaces. Where a change cannot be made compatible with an earlier form, the proposal should say so plainly and define the conditions under which the earlier path will stop being accepted. Test environments and published reference implementations can give operators and builders a way to examine the change before it affects an active coordination flow.
An emergency process may be necessary for a severe security issue, but it should be narrow and retrospectively accountable. The authority to pause a dangerous path is not the authority to permanently redesign the network in private. Any emergency action should identify its scope, publish the reason when doing so does not increase harm, and return to a normal governance process as soon as the immediate risk is contained. This discipline protects both the network and the legitimacy of its stewards.
9. Privacy and data boundaries
AI workloads can contain sensitive prompts, proprietary models, confidential evaluation material, or regulated data. A decentralized compute protocol should not pretend that openness removes these obligations. SNJU therefore treats data boundaries as workload-level requirements. Requesters should be able to indicate whether a task can run in a broadly open provider set, whether it requires stronger operator criteria, whether data movement must follow specified constraints, or whether a shared network path is inappropriate altogether.
The design goal is data minimization. Discovery should expose enough capability information for matching without publishing unnecessary operational detail. Task coordination should record the commitments needed for accountability without automatically storing payloads. Receipts should commit to relevant events and artifacts while avoiding the casual exposure of inputs or outputs. Encryption, secure transport, restricted execution environments, and confidential computing techniques may strengthen particular paths, but each comes with assumptions and implementation limitations that must be stated clearly.
Privacy is also a governance issue. Changes to receipt formats, logging expectations, or review procedures can change what information becomes visible to the network. SNJU should evaluate these choices not only for technical usefulness but also for the risk that they normalize excessive collection. A protocol that seeks open participation must remain explicit about what it observes and why.
10. Security model and resilience
Security in decentralized compute spans more than key management. It includes the integrity of workload definitions, the authenticity of provider capability statements, the isolation of execution environments, the durability of receipts, and the safety of governance processes. No single mechanism resolves all of these concerns. SNJU proposes a defense-in-depth posture in which different layers can be inspected and improved independently.
At the task layer, immutable references and signed commitments can reduce ambiguity about what was agreed. At the provider layer, attestation and performance history can inform confidence while remaining subject to review. At the execution layer, sandboxing, controlled runtime images, and workload-specific policy can reduce exposure. At the evidence layer, signed receipts and content-addressed artifacts can make later review more reliable. At the governance layer, transparent proposal processes and bounded authority reduce the risk of hidden parameter changes.
Resilience also requires graceful failure. Operators may go offline. Hardware may fail. A requester may provide an incomplete specification. A verification process may find that available evidence is insufficient. The protocol should represent these outcomes honestly rather than forcing every task into a false success state. Clear exception states, recovery procedures, and dispute paths are part of a trustworthy system. They help participants distinguish between an unavoidable operational event and a deviation that requires further action.
Incident response and disclosure
Security is improved by a credible response path after something goes wrong. SNJU should maintain a disclosure process for vulnerabilities in reference implementations, critical specification ambiguities, and provider-side behavior that threatens a workload class. Responsible disclosure channels, severity definitions, and coordinated remediation procedures can reduce confusion during an incident. The process should encourage reporters to provide reproducible evidence while avoiding public release of details that would make active exploitation easier.
After remediation, the community benefits from a concise record of what class of issue occurred, what scope was affected, what temporary controls were used, and what protocol or implementation changes followed. These reports should avoid exposing private task information. Their purpose is to help operators and builders understand which assumptions changed and how similar failures may be prevented. A decentralized system cannot depend on secrecy as its main security property. It must develop the habit of learning visibly from bounded, well-documented incidents.
11. Network economics without speculative claims
The economic question for a decentralized compute network is how to sustain useful contribution while preserving clear accountability. SNJU approaches this through protocol utility and task-specific commitments. Builders bring demand for execution. Operators contribute capacity under declared conditions. Verifiers and governors contribute review and stewardship where the protocol requires it. A healthy design should make each role's responsibilities legible and avoid rewarding activity that does not improve network usefulness.
Network economics should be evaluated through operational signals, not promotional language. Useful questions include whether requests are being matched to compatible capability, whether execution receipts are complete enough for the chosen workload class, whether challenge processes are proportionate, whether participation remains accessible, and whether governance decisions preserve a coherent standard. These are conditions that can be studied and improved over time. They are different from claims about market outcomes, which this paper does not make.
Early protocol design must also be willing to leave some mechanisms undecided. It is better to state that an operational detail needs testing than to pretend that a static formula can anticipate every workload and provider environment. SNJU intends to develop these mechanisms through prototypes, public technical discussion, and iterative governance processes. The guiding criterion is whether a rule makes decentralized compute more usable, inspectable, and sustainable for the participants who depend on it.
12. Development roadmap
SNJU is being built in stages because the network's difficult questions cannot be solved through branding alone. The first stage is protocol definition: establish a workload vocabulary, a provider capability model, a task state machine, and an initial receipt schema. The result should be a specification that builders and operators can critique before it is treated as stable infrastructure.
The second stage is coordination experimentation. This work explores how compatible requests and provider records can be matched, how execution conditions are negotiated, and how the system represents exceptions. The emphasis is on clarity of behavior. A prototype should make it possible to trace why a task moved from one state to another and what information each participant was expected to contribute.
The third stage is verification refinement. SNJU intends to test receipt formats, inspect the limits of automated checks, and define challenge pathways that are usable without becoming arbitrary. The fourth stage is governance formation, including documented proposal processes, scope for working groups, and methods for updating standards as evidence accumulates. Timing, sequence, and implementation detail may change as technical review reveals constraints. The roadmap is a direction of work, not a guarantee of a specific release outcome.
13. Risks and limitations
Decentralized AI compute faces substantial risks. Heterogeneous hardware can make compatibility difficult. Operators may have uneven reliability. Verification can be expensive or incomplete. Sensitive data may not be suitable for a shared provider environment. Governance can become captured by concentrated interests or slowed by procedural complexity. Malicious participants may try to misrepresent capacity, exploit workload definitions, or generate misleading receipts. Acknowledging these risks is necessary for responsible protocol design.
SNJU does not claim to eliminate these risks. The proposed mechanisms are designed to make them more visible and more manageable: structured specifications reduce ambiguity, capability records make matching more explicit, receipts preserve evidence, challenge processes provide a route for escalation, and governance creates a public path for evolving standards. Each mechanism can itself fail or be misused. The network must remain open to independent security review, operational testing, and revision when evidence shows that a rule is not working.
Participants should also understand the limits of this document. It is not a technical guarantee, a legal opinion, an investment solicitation, or a promise about the behavior of any future implementation. It describes a proposed framework. People considering participation should conduct their own technical, operational, and legal assessment appropriate to their jurisdiction and role.
Conclusion
SNJU is built around the belief that AI compute can be coordinated more openly without making trust disappear behind a slogan. The challenge is to replace informal trust with clear task definitions, bounded capability claims, durable receipts, and governance processes that participants can inspect. That is the work this protocol proposes to undertake.
The path forward is practical. Define the workload language. Make provider participation comprehensible. Test coordination flows. Improve verification. Publish the tradeoffs. Let builders, operators, and community stewards challenge the assumptions. A decentralized compute network earns relevance only when it helps people do real work with more clarity and accountability than the alternatives available to them. SNJU's aim is to create that condition.