Foundational infrastructure should have many implementations, not just one. Cloud

The optional reference-managed implementation, not the protocol itself.

Poiva Cloud now starts from an organization: users sign up with email and password, create the tenant, and receive an authenticated session for cloud APIs.

Open API docs Read community

What this page covers

Cloud remains optional.

No implementation should be required for compatibility.

Reference services should preserve extension boundaries.

Managed features must not redefine the core protocol.

Highlights

Protocol-native entry points for this surface.

Execution services

Mission orchestration, event processing, verification, and settlement workflows.

Review protocol

Interoperability

Cloud products should compete on execution quality, not ownership of semantics.

Read vision

Reference posture

A managed offering can prove viability without becoming the definition of the protocol.

Read governance

POST /api/cloud/signup
POST /api/cloud/login
GET /api/cloud/me
GET /api/cloud/organization
Bearer token sessions

Working principles

Keep the protocol stable while implementations evolve.

Cloud remains optional.

No implementation should be required for compatibility.

Reference services should preserve extension boundaries.

Managed features must not redefine the core protocol.

SDKs

Multiple language surfaces should target the same cloud-neutral semantics.

Browse SDKs

Cloud API

Signup and login are organization-first and email/password based.

Read spec

Roadmap

See when reference cloud capabilities fit into the public plan.

View roadmap

Next step

Implementation without lock-in.

Poiva Cloud can be useful, but the protocol only succeeds if organizations remain free to choose other implementations without losing portability.