# Economy, banking and infrastructure

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

Canonical: https://docs.bankeiz.com/infrastructure/
Reviewed: 2026-10-25; coordinated packages 129.0.0; ruleset 127.0.0.

## 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**

| Layer | Role | Implementation relationship |
| --- | --- | --- |
| Proof-native economy | Economic system | Source, rights, ownership and value remain inspectable. |
| Reality-grade banking | Interaction standard | Holding, receiving, transfer and evidence preserve those relationships. |
| Reality-grade infrastructure | Implemented primitives | Receiz 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. Original: Verify the enclosing artifact and required evidence.
2. Admission: Bind identity, rights, scope and predecessor.
3. Projection: Present supported fields and relationships.
4. Action: Use 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.

- [Integration guide](https://docs.bankeiz.com/integrations/)
- [Conformance and assessment](https://docs.bankeiz.com/conformance/)

## Implementation sources

- [Implemented capability map](https://github.com/kojibai/reality-grade-banking/blob/6c5d582/docs/current-function-boundaries.md)
- [Receiving requirements](https://github.com/kojibai/reality-grade-banking/blob/6c5d582/institution/receiving-standard.md)
- [Native assets and account proof contracts](https://github.com/kojibai/reality-grade-banking/blob/6c5d582/docs/native-assets-and-account-proofs-v129.md)

## Related documentation

- [Read the account without losing the source](https://docs.bankeiz.com/concepts/)
- [Build an implementation of the standard](https://docs.bankeiz.com/integrations/)
- [Assess an implementation independently](https://docs.bankeiz.com/conformance/)
- [Versions, schemas and implementation status](https://docs.bankeiz.com/compatibility/)