The co-op does not treat presence as a permanent record. It treats it as a temporary alignment of keys, machines, and flows.

A designer enters the space with a key that exists only for that session or for that specific thread of work. That key can be derived, rotated, or discarded at any time. It connects to the co-op through an access NFT or a proof derived from it. The proof satisfies a condition—“this key is allowed to interact with these machine contracts”—and nothing more is revealed. The system does not require a persistent identity beyond that condition being true at the moment of interaction.

When the designer submits a job, what reaches the machine is a compiled instruction set and a token flow. The machine contract checks that the tokens are valid and that the proof satisfies the access rule. It does not store who the designer is. It only processes: valid input → execution → output → completion state. The output carries a reference chosen by the designer. That reference can point to a pattern state, or just to the fact that this object exists. It does not need to bind back to a long-lived identity unless the designer decides to attach one.

Inside the space, multiple designers operate like this simultaneously. Each one brings their own keys, their own tokens, their own workflows. The system never merges them into a shared profile. It only sees flows passing through functions. A loom receives instructions, executes them, and clears the state. A cutter processes a file, returns a result, and resets. The machines do not accumulate memory of who used them.

Agents inside the co-op follow the same principle. A scheduling agent reads incoming token flows and arranges execution order to keep machines active. It does not build a persistent map of designers. It reacts to current state. Once a job is completed, the relevant state can be dropped or reduced to a minimal reference. The agent continues with the next set of inputs.

Tokens also remain fluid. A designer can route tokens into a workflow, have them consumed by a machine, and exit the space without leaving a trail of balances tied to a permanent identity. They can move tokens through fresh addresses, or use proofs that show validity without exposing the full path those tokens took. The important thing is that the system verifies conditions at each step, not histories.

Confidential interactions remain completely separate. If a designer is producing a custom garment for a buyer, the buyer’s data enters through an encrypted channel, is processed locally or in a bounded environment, and leaves as a result. That data never touches the co-op’s shared machine layer. The co-op only sees the final instruction set and the tokens that trigger execution.

Designers can stay for one session, run a series of jobs, publish or not publish their outputs, and leave. The only traces that persist are the ones they explicitly anchor: a signed pattern state, a garment reference, a proof they choose to keep alive. Everything else—intermediate steps, temporary keys, local computations—can dissolve.

This keeps the space operational rather than archival. It is built to process flows, not to store lives. The commons holds open design states. The co-op executes material transformations. Confidential channels handle private exchanges. Tokens move actions forward. Keys appear and disappear as needed.

Designers move through it without being fixed in place.