What you can carry. What you can trust.

A receiz is a proof object: a sealed file that carries its own verification material. Receiz is the proof-native artifact system where identity, ownership, history, and settlement continue around that object. Verification authority is the original file; settlement authority is replayable append-only ledger math. A verify link (/v) is optional public convenience for that same file.

Verification authority is original file bytes plus embedded verification material. Settlement authority is deterministic replay over persisted integer value fields and posting reference rate.

The sealed file is the proof object and source of truth. A link opens a public proof surface for it. Verify links (/v) are optional public convenience for that same file.

The file is the sealed file carrying embedded verification material. Depending on flow, it is a claim record, document/media artifact, or package file.

Share the file (or package ZIP). That is what verifies. Share the verify links (/v) only when optional public convenience is needed.

Choose Save file in the Sealed panel. It shows the filename and whether the result is a sealed file or a package. Keep that complete download: it carries the content and proof together. Open it in Verify; keep the Offline Verifier HTML too if you want to check it without a connection.

Deposit, transfer, reserve-note issue, and note-claim redemption all post append-only ledger events under one deterministic value contract.

The canonical value tuple is `amountUsdCents`, `amountPhiMicro`, and `usdPerPhiMicrocents`. Replay and reconciliation depend on this tuple remaining present and unmodified.

Custody is stored as integer Settlement Ledger Unit (SLU) micro values in `phi*` protocol field names (for example `amountPhiMicro` and `balancePhiMicro`) while account UI remains USD-readable.

A sealed portable settlement instrument (PNG, PDF, or JSON packet) whose verified claim is accepted locally at a Kai Pulse as Settlement; account posting is optional.

Local verification rejects altered bytes, invalid authority, broken predecessor history, and conflicting transitions. An accepted claim at its Kai Pulse is Settlement; optional account posting independently rejects duplicate projection.

Private and public ledger routes keep the same value and proof semantics while differing only in identity visibility. Independent verification stays intact across both routes.

Conformance publishes requirement rollups, source/runtime checks, revision anchors, and raw JSON artifacts for independent review.

Settlement is proof-native value: completion resolved by the deterministic record. Send it, put it to work in Market, or issue shares into a certificate.

Funded market sales, certificate purchases, and funded events add reserve. Until then, gains stay priced, sendable settlement that issues into certificates.

Reserve builds ownership. Settlement shares issue into certificates. Use reserve proceeds to issue notes.

Issue notes from reserve. Receive a note and receive funded value.

Settlement shares turn a position into a buyer-ready ownership object. Buyer gets the claim. Seller receives reserve.

You own a recorded share quantity in a specific Market asset, with its cost basis, current value, and proof trail. Exporting shares moves that quantity into an ownership certificate. For example, exporting 3 of 10 shares leaves 7 in the position and 3 in the certificate. The original proof object’s ownership transfer is a separate action; any additional rights to the underlying work must be stated in its terms.

The displayed value uses your quantity and current price. The trade preview shows the execution quote and costs, including the buy/sell spread. Proceeds retain their exact Reserve/Settlement split: the funded portion posts to Reserve, and the remainder stays Settlement. Review that split before confirming. A higher displayed price or an exported certificate alone does not fund a payout.

Funded value posts to reserve. The rest remains settlement, ready to issue into shares for a buyer-funded purchase.

The Wire preview currently quotes $35 plus 5% of the gross amount. Net delivery must remain positive after fees, with enough Reserve to cover the wire. Wallet shows the beneficiary, fee, net delivery, submission cutoff, and estimated arrival window before submission. The arrival window is an estimate; a request is not confirmation that the bank delivered it.

A share holding records its asset and quantity. Copyright, royalties, or other rights require an explicit grant in the relevant terms; the quantity alone does not establish them. Inspect the original, certificate, and any attached terms for the specific asset before purchasing.

It verifies the preserved content and its carried proof, including the sealing coordinate. The first seal carries creator and initial ownership; verified handoffs extend that history. A statement inside a file remains a statement: sealing it does not independently establish that an event happened as described.

The sealing coordinate records when the seal was made in Kai’s deterministic sequence. A verifier checks that carried coordinate with the proof. A date written inside your content describes the content; it does not replace the sealing coordinate or independently establish the event’s time.

Verification checks whether embedded proof data still matches the file bytes and record fields. If anything changes, verification fails.

Tampering breaks bindings. Verification rejects. The file no longer matches the issued record.

Yes. Verify runs fully offline. The offline verifier checks integrity locally with no network calls and enforces the same deterministic bundle checks.

Yes. Record, Seal, and Verify all run offline. No account is required for offline operation.

No. Account access is optional. It adds custody, public identity publishing, messaging, and billing tools, but is not required for offline Record, Seal, or Verify.

Trusted verification requires signatureV4. It verifies canonical payload hash, root-key policy, device certificate chain, certificate validity window, and final payload signature. This hard-fail path blocks unsigned, out-of-policy, expired-cert, or tampered bundles.

No. Verification is public and free. An authenticated Free account includes authorship, signing, custody, ownership, general business tools, AssetSeal, and non-AI WireProof.

No. Record, Seal, and Verify do not require one. A free account opens your public identity, embeds, live work, and basic custody.

Sealed files in custody tools: Archive for your records, Received for opened external records with context.

Authenticated Free includes proof, authorship, signing, receiving, custody, ownership, business entity, payments, analytics, AssetSeal, and non-AI WireProof.

Premium is intelligence that stays with you, knows your work, and evolves with it. Create with proof-native Creator AI and own one persistent Twin carrying continuity, memory, relationships, and public presence. Premium includes 500 monthly credits and remains $12/month or $99/year.

Business carries Premium forward and adds 7,500 monthly credits plus your Receiz domain, with your identity as the homepage, team coverage, and a connected close. Business remains $149/month or $1,499/year.

Automation keeps opportunities moving without waiting on you through outreach, lead generation, introductions, APIs, webhooks, memory, and workflow execution.

White-label does not start in Business. It starts at Enterprise.

AssetSeal issues one verifiable origin record, then appends custody/authorship events without rewriting origin.

Existing records remain valid and verifiable. Verification is never gated by plan. Paid-only controls revert until the plan is re-enabled.

People can explore your work, ask your Twin questions, and move into booking or the next action from the same public identity. They arrive with your context already present, rather than having to piece you together across disconnected pages.

Discovery reaches beyond the profile and keeps the same relationship moving after the first touch.

One starts the relationship. The other extends its reach without breaking the same identity and thread.

Yes. Embed your Twin on a website or campaign, or connect a custom domain to your public presence. The same identity remains behind those entry points. You choose where people meet you without rebuilding a separate presence for each page.

Yes. Public identity, messaging, streaming, and embed routes are documented on the Developers page.

Use Standards for canonical schema boundaries, trusted signature v4 profile requirements, error contracts, and conformance vectors.

Use Developers for endpoint contracts, offline record/seal/verify integration patterns, and trusted signature v4 verification policy details.

Use the Settlement Standard tables: Claim-to-Code Traceability, Guarantee Boundaries, and Conformance Controls. These map each trust claim to route/function sources and verification evidence.

Use the Value Source Appendix for pulse authority, deterministic derivation procedure, persisted-field contract, and replay validation checks.

Use Trust for policy posture and route links, then Status for live operational reliability.

Use Governance for control owners, mandatory approval paths, separation-of-duties policy, and published evidence-cadence artifacts.

Use Status for live route health and incident visibility.

Start your next experience with the identity, proof objects, and verified history you already hold. New events append; earlier history stays intact. New uses preserve the evidence of what you created, owned, and did.

It is your Receiz identity together with the proof and history you carry. Your Receiz Key preserves portable identity continuity; your proof objects preserve their own content and history. A profile or Twin presents that continuity. Keep the complete exported sources you want to restore, not just a screenshot or profile link.

Your Receiz ID carries identity continuity. Your proof objects carry verifiable content and history. Your profile presents them, and your Twin lets people interact with your presence. These are distinct parts of the same system: changing the surface does not create a new original or erase the history it carries.

No. Showcase visibility and access permissions govern what others can see. An exported file gives its recipient the content and proof inside it. Choose what you share.

Current supported browsers seal locally. Older Safari browsers can use an online sealing path that sends the file for processing. Publishing to a public showcase is a separate action governed by visibility and access controls. For standalone local work, keep the offline Studio available on your device.

The original object, its creator, and its earlier history remain. An authorized ownership transfer appends the new owner and handoff. It does not rewrite the first sealing or transfer the sender’s personal identity and private history to the recipient.

Yes. Wildz and Receiz Commerce are open-source implementations and reusable kernels. A verifier checks the object’s evidence; a destination app supplies actions for its supported formats. Wildz continues portable creature history; Market imports position and share-certificate objects; identity restore accepts complete identity proof. Use the compatibility guide to choose the matching entry point or build another with the SDK, MCP tools, and AI skills.

You can start with an idea and a coding AI. Give it a working open-source kernel, the Receiz SDK, MCP tools, and AI skills, then describe the experience you want it to build and test. The kernel supplies implemented proof, identity, and continuity to build on. You still choose the behavior and check the result before sharing it.

An export carries the state sealed inside it. Your Receiz Key carries identity and included account state; proof objects carry their content and history. Later events arrive as verified additions. A Twin reads the sources and memory it is permitted to use; its visible conversation is not a replacement for those sources. Keep a current export of what you want to carry.

Use another device that still holds your identity, another accepted identity proof, or your existing PBI/passkey recovery path. If none remain, there is no proof here to restore that identity from: a username or public profile link cannot recreate private proof. Keep a separate copy of your key, any file password, and complete proof objects before changing devices.

Verified local truth is durable truth. Receiz uses it directly instead of waiting for a session check, database lookup, or another proof check to tell you what you already hold. Background synchronization can append verified additions without replacing the settled surface. That removes repeated work from the path between you and your object.

No. The complete source and its embedded proof can be verified locally with the offline verifier. Keep both the source and the verifier available on your device. Servers can deliver files you do not yet hold, publish additions, and run remote services; their availability does not decide whether your held proof is valid. A screenshot, link, or server response cannot replace the original.

No. A file you have not received still needs to arrive, new proof must be verified, and remote actions depend on their services. The speed guarantee protects known verified truth: those other tasks must not make it disappear or force you to start loading it again.

The conversation’s working context is not the source of your history. Held proof and admitted memory remain available for retrieval beyond that working window. An AI answer must use the sources it can access; retaining history does not mean every answer has read every object or has permission to do so.

Offline Studio is the standalone on-device runtime for Record, Seal, and Verify. It generates verifiable artifacts locally and preserves original file format behavior for sealing flows.

Yes. Record, Seal, and Verify are all offline-capable. Verification remains deterministic from file bytes, and does not require a network call.

No. Account access is optional and not required for offline Record, Seal, or Verify.

Accounts add authenticated authorship, custody tools (Archive and Received), public identity publishing, messaging, team collaboration, and ownership controls.

Trusted signing material is provisioned to the device. Once provisioned, the offline runtime keeps issuing trusted offline Record and Seal outputs on that device.

Use the Offline Verifier HTML. It is the canonical offline verification reference and runs locally without account access.

Use Record Moment (/record) for moment claims, or Seal File (/seal) for files/folders. Keep returned file bytes unchanged.

Yes. Receiz supports common document/media formats, generic binaries, and package/folder flows.

Verify from file bytes, online or offline. Matching files verify; altered copies fail.

Screenshots fail. Originals verify. A screenshot does not carry embedded verification material.

Receiz uses the identity held on this device and continues to the requested page. On a new device, it can create a local Receiz ID. To continue an identity you already hold elsewhere, restore with its accepted identity proof or use your existing recovery method.

No. Receiz creates a local identity when this device does not already hold one. If you are moving an existing identity to this device, bring your Receiz Key or another accepted recovery proof so you continue as the same person.

Yes. Passkey-only onboarding is supported. Email is added later when needed, and magic-link then resolves to the same Receiz account.

After they connect passkey from Account settings, passkey and email sign in to the same account. The two methods do not create separate users.

Yes. Once email is linked to that profile, future magic-link sign-ins route to the same Receiz identity.

Receiz signs the recipient in via magic-link. If the recipient is new, Receiz creates the account during that flow. After signing, they use passkey or email to access the same account.

Map local users by OIDC `sub` (stable subject). Treat email as mutable profile data. This prevents identity split when users switch between passkey and email.

Create and manage OIDC clients in Receiz Connect, then implement Authorization Code flow with PKCE using discovery metadata.

WireProof is an authenticated core proof operation for payment evidence: a sealed file plus verifier URL or QR.

Business adds your Receiz domain, identity homepage, team coverage, connected close, and 7,500 monthly credits. Automation adds outreach, lead generation, introductions, APIs, webhooks, and workflow execution. WireProof remains authenticated core.

No. Signing is optional and used when teams need human-origin witness attestations.

Yes. Unsigned demos are available. WireProof is included with authenticated Receiz identity; paid plans add domain ownership and automated operations.