Skip to documentation
Reality-grade bankingDocumentationOpen implementation
Documentation contents

Start

Economy, banking and infrastructure

The economic system, its interaction standard, and the implemented primitives that connect them.

Reviewed 2026-10-25 · SDK 129.0.0Read Markdown ↗

Proof-native economy

A participating claim carries the required source, rights and evidence. Ownership, supported value and causal predecessors remain connected to the original. A label or account display can present that evidence, but cannot create it. Different claims require different proof: authorship is not physical custody, a market observation is not a transfer, and a price calculation is not available liquidity.

Reality-grade banking

Reality-grade banking is the standard for holding, inspecting, receiving and deliberately moving that value without breaking its source relationships. It sets requirements for admission, exact execution, retention and recovery. Independent implementations can offer different interfaces while preserving the same underlying proof and authority boundaries.

The three layers
LayerRoleImplementation relationship
Proof-native economyEconomic systemSource, rights, ownership and value remain inspectable.
Reality-grade bankingInteraction standardHolding, receiving, transfer and evidence preserve those relationships.
Reality-grade infrastructureImplemented primitivesReceiz SDK, MCP and AI Skills expose coordinated contracts.

Reality-grade infrastructure

Receiz implements identity, sealing, verification, ownership, Settlement, Notes and continuity. The SDK composes application operations; MCP exposes supported tools; AI Skills describe the corresponding workflows. They are coordinated ways to use the same primitives. A tool connection or installed package does not introduce a new issuer, private account permission or financial execution authority.

Source and representation

Authority flows from the original into a supported view
  1. OriginalVerify the enclosing artifact and required evidence.
  2. AdmissionBind identity, rights, scope and predecessor.
  3. ProjectionPresent supported fields and relationships.
  4. ActionUse the exact authorized execution contract.

A self-hashable subpayload validates its deterministic projection. It does not replace admission of the enclosing stronger artifact. A database, server response or interface index can append or display supported observations; it cannot erase or outrank a retained verified original.

Implement the standard

Begin with one clearly scoped operation. Name the receiver, exact units, accepted source, intended change and evidence of completion. Use the implemented primitive directly, retain the original request before irreversible work, and exercise refusal and interruption paths. Conformance records describe the actual assessed build, role, roots, runtime and evidence; a name or version number alone does not qualify an institution.

Implementation sources

Inspect the exact path.

Source links retain revision 6c5d582. Read the documented operation and assessment scope alongside its code.