FAQ for teams, operators, and institutions.

Receiz is a deterministic verification-and-settlement platform. 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.

Both. The file is the source of truth. 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.

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) issued from reserve value and redeemable later through verification + claim posting.

Claim routes validate packet authenticity and claim state before credit posting. Invalid token, invalid state, or already-claimed notes hard-fail with no settlement credit write.

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.

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

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. Plans unlock authorship, custody, and business tools.

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.

Free turns the work into a live demand surface.

Authorship keeps authorship and custody attached to what is yours.

Business moves the public close onto your domain.

Automation keeps follow-up going without waiting on you.

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.

It turns the profile into a live surface where people arrive in context and move into the next step.

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.

They let people land in context and move straight to the right next step.

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.

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 ID is passwordless account access. Passkey (WebAuthn) is default, and email magic-link is fallback or alternate login method. Both methods resolve to one account identity, and that identity continues across every Receiz experience, your domain, external apps, and real-world entry points using Receiz Connect.

No. If a user is new, Receiz automatically creates the account on first successful passkey or magic-link login.

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 one included automation for payment proof: a sealed file plus verifier URL or QR.

Automation adds what payment proof needs at scale: APIs, webhooks, structured claims, batch issuance, delegated issuers, org archive/export, and higher-volume execution. Verification stays public.

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

Yes. Unsigned demo flows are available. Signed and advanced controls require account + plan entitlement.