Platform and signup

Reindeer gives every customer its own cell. A separate platform deployment takes signups and decides who gets a cell. The platform holds no customer content: there is no swarm, no key-block store and no epoch key.

Signup

On the platform console’s signup page the founder gives:

• the organisation name, their own name and a contact email,
• a statement on the source and licence of the data,
• the version of the terms of service they accept,
• a confirmation that the organisation may store and process that data,
• and a passkey.

Nothing is stored until the passkey is created. Then one transaction creates the founder’s account (role owner, which can read only its own organisation) and the organisation, waiting for activation.

Signup brakes

Signups pause while 100 organisations wait for activation. One network (an IPv4 /24 or an IPv6 /48) may have at most three organisations waiting at once. One address may sign up three times, then once every ten minutes.

Activation

An operator reviews the organisation and requests its activation; a second person outside the requester’s chain approves it. Activation registers the organisation’s cell and, once the cell is ready, hands the founder the cell’s first administrator invite.

Suspension

Any operator suspends an organisation at once with a reason, which cancels its open activation and resume requests. Lifting a suspension needs a request and a second approver. Every change and every staff read of organisations enters the audit log, and every organisation has an append-only history.

What comes next

• Cell provisioning for activated organisations (by hand until then).
• Plans with hard limits on stored encrypted bytes, monthly egress and daily ingest, with warnings from 80 percent. At a limit, ingest and new exports stop while reads, deletions and the audit trail stay open.
• Daily metering per cell with signed usage reports, and signed monthly statements per organisation.