A business development project exploring an Arabic-first pay-and-receive wallet, from concept and operating model to a user experience and testable technical components.
Decisions began with the user’s needs and what it would take to operate the product, then became a user journey and requirements that can be implemented and checked.
The hypothesis: simplify digital-asset payments around two clear actions, Pay and Receive, with personal and small-business accounts under one identity and no need for the user to manage ETH for each operation. This remains a hypothesis under test; independent market research, customer numbers and revenue do not yet establish adoption.
I led the concept, user experience and operating model: Arabic first, a unified pay-and-receive flow, separate personal and business-use accounts, and administrator-funded network fees. I also directed recovery and governance choices, identity, motion and sound reviews, and follow-up on tests and device checks, supported by AI-assisted implementation and review.
The scope includes child accounts, beneficiaries, account groups, split payments and recurring transfers that require fresh approval when due. The model proposes a capped QIRSH usage fee and administrator-funded ETH costs. These decisions became a bilingual journey, original identity, investor pitch, interactive prototype, Android components, contracts and an SDK; they are not yet proven as a revenue-generating business.
I separated receiving a request from approving it. The payer can check the recipient, amount and source account before deciding.
Try paying
Payment flow in the pitch · original p. 7I kept Pay and Receive the same for a small-business owner and for personal use, while giving each account its own history. The demo opens on the request amount.
Try requesting a payment
Personal and business accounts · original p. 6Select a layer to understand its responsibility, its relationship to the experience and its evidence limits.
This architecture describes the source product. The downloadable demo is an isolated experience with a different scope, explained in the demo section.
Follow the payment journey step by step. This explains the product’s states and decisions; it does not submit a transaction.
This is the source product flow and its new local components; complete integration with the visible V5 controllers is unfinished. This walkthrough explains the states only.
The recipient selects an account and amount, then shares a request that the payer accesses through an available product channel.
Request available for review · Request information is available. Settlement has not started.
The payer reviews recipient, account, amount, fees and total before deciding to submit.
Awaiting the user’s decision · Clear transaction details represent review, not a payment receipt.
Required approvals are completed, then the payer authorizes the operation through the device prompt. The path journals signing state before key access and exact signed bytes before submission.
Approval for this operation · Authorization permits the flow to continue; the result comes from execution and confirmation.
The operation enters the sponsored execution path. Provider acceptance remains pending; a timeout does not permit a new submission without resolving the previous operation’s state.
Pending confirmation · Submission alone does not establish receipt of payment.
An independent path checks the operation, events, nonce consumption and canonical-chain finality. Only then are the receipt and success feedback tied to the appropriate confirmation.
Confirmation backed by execution evidence · This explains the source product flow. The demo simulates these states using illustrative data.
Each decision affects the experience, operating costs and what needs to be validated.
| Decision | Reason | Trade-off |
|---|---|---|
| One interface for individuals and small businesses | Keep pay and receive understandable while organizing accounts by use. | A named account does not change its holder’s identity or verify a business entity. |
| NFC with clear alternatives | Reduce steps to a payment request when NFC is available, with QR and username alternatives. | Different device capabilities require fallback paths and physical-device testing. |
| Explicit approval before submission | Tie the decision to a clear recipient, amount and fee. | Approval adds a deliberate step and requires correct cancellation and continuation handling. |
| Network-fee sponsorship | Remove the need for users to manage ETH in the intended payment experience. | Funding and availability responsibilities move to the operating model and sponsor. |
| Separate private data | Reduce exposure of receipt details and private information on the public record. | Access permissions, storage and independent review still need to be defined and validated. |
| Custom Arabic recovery | One root restores primary and child accounts under the selected language constraints. | QIRSH-AR1 is custom; it requires explicit support and does not assume BIP39 compatibility. |
| Explicit issuance, burn and upgrade authority | Allow administration of issuance rules, operations and future changes. | Centralized issuer authority remains; upgrade scheduling does not remove that dependency. |
This case-study material was prepared on 1 November 2026. The latest recorded combined source build is dated 13 October 2026; the evidence below retains its date and scope and is not a fresh network verification.
This portfolio does not claim a public launch, real customer payments or independent security certification.
These sources explain the underlying technologies; they do not establish their implementation or results within QIRSH.
A standalone interactive QIRSH experience using synthetic data, with no real funds or transactions. It demonstrates the journey; it does not run the original connected wallet or administrator powers.
Explore payment, review and receipt flows using illustrative data. Each version’s scope explains what it actually supports.
The demo is being prepared.
افتح الصورة الأصليةOpen the original image
Isolated browser prototype · Synthetic data
Explore the wallet demoFor a project connecting business opportunity to a clear experience and delivery plan, or a role in business development and digital marketing.
Project details could not be loaded.