Bankeiz public reading · Open in Bankeiz

Build your own bank. Receive the same money. | Reality-Grade Banking

Build an independent bank, wallet or merchant receiver with Receiz. Explore complete Originals, legitimate transfers and the published receiving requirements.

Skip to content
Enter bank

BUILD YOUR OWN BANK.RECEIVE THE SAME MONEY.

Bankeiz is one implementation.
Yours can be another.

BANKEIZAccount
Available in this illustration$1,000
AccountAssetsLedger
Financial OriginalSource · ownership · authorityDenomination · continuityEvidence travels with the value.
Follow a transfer
YB
YOUR BANKIndependent institution
Your receiving position$0
↙ Receive↗ Pay
Your interface.Your infrastructure.

Different applications. Same financial value.
Independent verification.

Deterministic illustration · no payment is executedFinancial receiving still requires an applicable, qualified implementation.
Illustration: two proof objects remain connected through one transfer and its source layers.

THE APPLICATION CHANGES.
THE ORIGINAL KEEPS ITS HISTORY.

Follow $1,000 across three different applications. Each supported transition preserves the original lineage and assigns the transferred portion to the recipient.

Deterministic illustration · no payment is executed
Simple viewProof view
B
BankeizBankeiz account
Example

Proof-native position

$1,00010.000000 Φ
One source lineage
Send $400
YB
Independent BankYour independent bank
Example

Proof-native position

$00.000000 Φ
One source lineage
Send $250
M
Merchant WalletMerchant receiver
Example

Proof-native position

$00.000000 Φ
One source lineage
Ready to receive

$1,000 total · counted once 10.000000 Φ · exact illustrative position

Start againPlay sequence

Start with Bankeiz. Send $400 to the independent bank.

Exact teaching units: 10 Φ initially; then 4 Φ and 2.5 Φ transferred. The fixed fictional display quote is $100 per Φ. It is not a live quote, funding source or redemption promise. No signing, account, payment or credit is created.

A PAYMENT PROVIDER
IS NOT THE MONEY.

Compare the same commercial stages. Conventional providers support genuine settlement and financial ownership. The distinction here is how another application receives and establishes the evidence.

01Customer pays02Receive and verify03Merchant receives04Pay the supplier
Traditional provider integration
Customer→Provider→Business

Customer pays

A supported payment method starts a $250 payment.

Connected to a service.
Proof-native receiving
Sender→Original→Your receiver

Customer pays

A legitimate $250 proof-native payment is initiated.

Receive and verify the financial object.

Same commercial purpose. Different receiving architecture.

Explore the payment and onward-use story

YOU CAN COPY THE NUMBER.
YOU CAN’T COPY THE AUTHORITY.

Two real synthetic fixtures. The same $2 display. One carries the expected scoped delivery authority; the other deliberately carries a mismatched authority binding.

Authentic synthetic fixture01
$2.00

Complete carried source + expected delivery binding.

Not run · verify to inspect the actual evidence
Authority-mismatched fixture02
$2.00

The visible amount survives. The required binding does not.

Not run · the display cannot establish authority
Verify both

The genuine v129 read-only reader loads only when you choose Verify both.

Synthetic fixtures · source and delivery-authority inspection. No funds are authorized.

Inspect verification scope · not a financial acceptance

Explicit synthetic test roots, separate from production trust. The reader checks carried source and scoped delivery authority. Current spendability, live custody, conflict resolution, financial acceptance and credit authorization are not checked. An exact copy can remain authentic; it cannot acquire another right to spend.

Inspect the real reader ↗

THE NUMBER IS THE VIEW.
THE ORIGINAL IS THE EVIDENCE.

A receiving application establishes the necessary claims before making value available. Success at one layer does not silently grant the next.

  1. 01Authenticity

    Are the original bytes, carried sources and signatures valid under the declared trust?

  2. 02Current authority

    Does this receiver hold the necessary current ownership, custody and exact heads?

  3. 03Accepted financial state

    Did the legitimate transition commit atomically, with once-only consumption and credit?

NOT EVEN BANKEIZ
GETS AN EXCEPTION.

November 2–4, 2026: Create an Asset had to carry the same Original through creation, signing, publication and complete public presentation.

01

Keep the Original

Exact locally sealed bytes, accepted predecessor and append. Hidden historical membership stays intact.

02

Complete publication

Durable recovery continues the existing publication. It preserves the exact Source and identity binding.

03

Carry the accepted signature

The signed acknowledgment describes the accepted operation. No new signing ceremony substitutes for the held PBI.

04

Present accepted state

Public and private readers carry the same available evidence. Prepared HTML reuses accepted history and applies the new state.

Original facts + exact PBI deliveryNov 2 · exact creation pathNov 3 · retained append continuityPublication regression testsPrepared reader regressions

These are creation, publication and presentation integration requirements. A display defect is not automatically a cryptographic rejection. These changes do not establish financial receiving or spending qualification.

The application must demonstrate
why the Original is legitimate.

YOUR CODE.
YOUR INTERFACE.
YOUR INSTITUTION.

Start with the actual v129 contracts and examples. Your implementation supplies admitted sources, exact consent, qualified custody and the atomic host boundary.

  1. 01Choose the capability and rail
  2. 02Open the complete Original
  3. 03Verify source and pinned trust
  4. 04Establish current authority
  5. 05Check receiving and custody
  6. 06Execute the authorized transition
  7. 07Keep exact recovery
  8. 08Reverify the result
  9. 09Support the next legitimate transfer
01 / Choose the capability

Choose the capability and rail

Declare exactly what your receiver supports. Settlement and Reserve keep their own source and custody requirements.

Read the applicable contract ↗
Actual SDK boundary fragments · v129Copy code
import type {ReceizClient} from '@receiz/sdk';

type Edge=ReceizClient['value']['edge'];
type AdmittedInput=Parameters<Edge['planReserve']>[0];
type CommittedRecoveryInput=Parameters<Edge['createRecovery']>[0];

// The host supplies admitted sources and binds the exact amount, rail,
// participant heads, application and consent. A plan is not a payment.
export async function inspectBothReceivers(edge:Edge,input:AdmittedInput){
 const wrapper=await edge.planReserve(input);
 await edge.inspect(wrapper.plan,{
  participantId:wrapper.sourceParticipantId,expectedRail:'reserve',
 });
 await edge.inspect(wrapper.plan,{
  participantId:wrapper.destinationParticipantId,expectedRail:'reserve',
 });
 return wrapper;
}

export async function prepareExactTransition(edge:Edge,set:unknown,applicationId:string){
 const verified=await edge.verifyTransitionSet(set,{audience:applicationId});
 return edge.prepareCommitSet(verified);
}

// Between preparation and recovery, the qualified host store must atomically
// commit ALL participants or NONE and retain real SDK-issued custody.
// No generic SQL callback or caller-created object can replace that boundary.
export async function receiveActuallyCommittedValue(
 edge:Edge,committed:CommittedRecoveryInput,senderParticipantId:string,receiverParticipantId:string,
){
 const recovery=await edge.createRecovery(committed);
 // The host must durably retain this exact recovery before confirmation.
 // These fragments expose SDK boundaries, not a complete host adapter.
 await edge.confirmReserveSend(recovery,{
  applicationId:committed.applicationId,
  participantId:senderParticipantId,
 });
 return edge.receiveReserve(recovery,{
  applicationId:committed.applicationId,participantId:receiverParticipantId,
 });
}

This existing example demonstrates Reserve edge methods. It does not implement a complete receiver or turn Reserve into Settlement. The host must genuinely admit sources, atomically commit every participant and retain exact canonical recovery.

Start from the receiver kit.

Node.js 24+. Run the checks. Inspect an Original. Open the conformance workspace.

Copy commands
git clone https://github.com/kojibai/reality-grade-banking.git
cd reality-grade-banking
npm ci
npm run receiver:check
npm run receiver:inspect -- /absolute/path/to/original-note.png
npm run conformance:contracts
npm run dev

YOU DON’T NEED OUR PERMISSION.
YOU NEED THE EVIDENCE.

Build your own interface, infrastructure and institution. Published receiving requirements can be implemented independently; production readiness must be established for the exact capability.

Open the real conformance workspace
Current institution assessmentnot-assessed

Not a failure. Not a production approval.

What is assessed?
Receiver + capability + rail + build + environment
What counts?
Independent, applicable technical evidence
What does not?
Branding, a copied balance or a self-declared badge

THE NETWORK DOESN’T
NEED ONE OWNER.

Different institutions, applications and storage. Every receiver establishes the evidence for its own legitimate transition. Bankeiz is one participant.

BBankeizIndependent receivingYBIndependent BankIndependent receivingMMerchant WalletIndependent receivingSSupplier AppIndependent receivingABAnother BankIndependent receiving
Φ Original + continuing evidence

Bankeiz must establish source, current authority and the accepted transition. It does not approve every later transfer by another implementation.

Every new conforming receiver
expands where the value can go.

RECEIVE VALUE.
USE IT AGAIN.

A restaurant pays its supplier. The supplier pays a distributor. Another business receives the next legitimate payment. Different applications can carry the same necessary evidence.

Receive. Pay. Continue.

01RestaurantReceives a payment
02SupplierVerifies the supported next transition
03DistributorVerifies the supported next transition
04Another businessVerifies the supported next transition

Illustrative continuation · no production transactions are asserted.

The initial entrance

Fiat funding uses
its actual supported rail.

Funding, reserve admission and any external settlement depend on the route’s real contracts and financial infrastructure.

The next use

Proof-native circulation
preserves its source.

An admitted Original can continue through legitimate transitions between conforming receivers. Another fiat funding event is not invented for every onward payment.

Proof-native value stays usable as it moves from one recipient to the next. Each accepted transfer preserves the source, ownership and continuity needed to receive it and use it again.

THE REQUIREMENTS ARE PUBLISHED.
THE IMPLEMENTATION IS OPEN.

Receiz supplies proof infrastructure. The financial Original carries its evidence. Independent implementations establish the receiving and execution requirements.

01Receiz proof infrastructureExact bytes · canonical trust02Financial OriginalSource · ownership · continuity03Independent implementationsBankeiz · your receiver · other apps

The Original carries necessary evidence. Its authenticity is distinct from current custody and legitimate financial execution.

Receiver kit

Start with the implementation path, capabilities and exact v129 toolchain.

institution/README.md
Receiving standard

The normative source, authority, custody and continuity requirements.

institution/receiving-standard.md
Machine-readable profile

Inspect supported capabilities and the current not-assessed status.

institution/receiver-profile.json
Independent assessment

Specify the implementation, rail, build, environment and applicable evidence.

docs/conformance/integration-and-assessment.md
Qualification checklist

Positive, refusal, concurrency, recovery and real-device evidence.

institution/qualification.md
SDK example

The actual edge inspection, preparation, recovery and receiving fragments shown here.

institution/examples/accept-money.ts
Receiz developer infrastructureConformance workspaceAuthority boundary tests

BUILD YOUR OWN.
THE PROOF STILL HAS TO HOLD.

You don’t have to become Bankeiz or operate on our application servers. Build your bank, wallet or merchant application. Receive the Original. Establish authority. Execute the legitimate transition. Carry its proof forward.

Build a receiverRun the conformance testsExplore the source
Bankeiz→Your Bank→Another receiver
Φ Financial OriginalIts evidence stays connected.
Focus on the Original →

THE APPLICATION CAN CHANGE.
THE MONEY KEEPS ITS PROOF.

Reality-Grade BankingBuilt on Receiz. Implemented by Bankeiz.
Open to independent implementations.
The Original carries the proof.

Public source directories