Protocol · Architecture
A request becomes a job.
A job becomes evidence.
Scalar is designed so that computation, judgement and provenance are separate concerns performed by separate participants. This page describes the intended design, not a live production network.
Lifecycle
Seven stages from request to verified result
Each stage exists to remove a specific assumption an application would otherwise be forced to accept on trust.
1 · Job specification
A request becomes an explicit specification: what is asked, what inputs are permitted, what must be returned, what counts as success and how the result can be tested.
2 · Decomposition
Jobs are broken into bounded work packets. A packet is intended to be small enough to isolate, verify and reason about — and to limit how much any single participant can see.
3 · Distribution
Packets are routed to eligible workers. During controlled stages the coordinator is operated by the company; that is a temporary property of the current stage.
4 · Isolated execution
A worker executes only its packet, only within permitted resources, and returns output alongside signed execution evidence.
5 · Independent validation
Validators reproduce, compare or otherwise test the returned work against the specification. Disagreement raises a challenge rather than silently discarding the result.
6 · Provenance (Braid)
Job, work and validation lineage are recorded together so an accepted result carries a history that can be inspected later.
7 · Delivery and absorption
Accepted results are delivered to the requesting application and may be absorbed into Cortex as reusable, permissioned context.
Roles
Who does what — and who is not allowed to do it
Separation of duties is the structural reason a Scalar result is intended to mean more than a single provider's answer.
Useful-work miner
Receives an isolated work packet, executes it within the permitted models, processes and input boundary, and returns signed execution evidence. A miner never decides whether its own work is accepted.
Security model
Designed against the participant, not for them
These are design principles under active development. None of them should be treated as an audited guarantee today.
- 01
Job isolation
A worker should never need the whole picture to do its part. Packets carry the minimum context required.
- 02
Separation of duties
Performing work and judging work are distinct roles. A worker does not accept its own output.
- 03
Adversarial validation
Validation is designed to be worth attacking. Disagreement is a first-class outcome with a resolution path.
- 04
Reproducibility
Where a job class permits it, work must be re-runnable from recorded inputs and versions.
- 05
Attributable identity
Participants are pseudonymous but persistent, so behaviour over time is attributable.
- 06
Recorded failure
Rejected and challenged work is recorded, not erased. Failure data is part of the network's value.
Decentralization
Decentralization is a process with stages
Claiming a network is decentralized before it is would be the easiest thing to do and the least useful. Here is the intended progression.
- Stage 1Controlled
Company-operated workers, validators and coordination. Used to test job isolation, validation and failure handling.
Current design target - Stage 2Federated
Approved independent operators join. Multi-validator agreement and published specifications are exercised.
- Stage 3Public testnet
Broader participation, developer interfaces, adversarial testing and public telemetry — subject to readiness.
- Stage 4Distributed network
Progressive reduction of central coordination under published network rules, security review and legal review.
What is not true yet
The honest state of the architecture
Architecture without validation is a diagram. The parts of Scalar that matter most are the ones still being tested.