An Open Mobility Network for Independent Operators

Executive thesis

1. A shared network, familiar journeys

JURNE, pronounced “Journey”, proposes an open mobility network connecting passengers, drivers and independent licensed operators. Its consumer promise is deliberately familiar: request a journey, understand the fare, travel with an identified operator and see what happened to the payment. Behind that experience, separate businesses could share demand, reward rules and settlement records without surrendering their identities. London is the first intended market, beginning with controlled participation and coverage rather than a claim of city-wide availability.

The consumer brand and network infrastructure serve different purposes. JURNE's interface helps a passenger find and understand a service. The shared layer would help participating operators exchange eligible requests, recognise benefits earned elsewhere and reconcile what each business owes. Joining would not turn an independent operator into a franchise, make the network an owner of drivers' vehicles, or remove the need for accountable service management. Any independent operator meeting the applicable requirements could seek admission; an application would not itself create access to passengers.

The problems to validate are fragmented demand, repeated integration work, unclear earnings information and loyalty benefits that stop at one provider. Their severity will differ between operators and places. This paper does not assume every incumbent handles these badly or that passengers will switch because a ledger is decentralised. The commercial test is whether shared infrastructure improves completed journeys and repeat usage at a sustainable contribution margin.

Four proposed advantages guide the design. Bounded automation could reduce repetitive support and reconciliation work. Integrated payments could make charges, deductions and cash-outs easier to follow. Reusable Web3 components could reduce duplication between independently governed participants. Shared participation could improve decisions affecting drivers and operators. Each is a hypothesis to measure against a simpler alternative. Blockchain does not reduce the price of a vehicle, and driver-supplied vehicles are not a unique JURNE advantage.

This is Version 0.1, prepared on 2 November 2026, not an operational network or token offer. JURNE is currently operated personally by Hussain Razzaq, trading as Jurne Technologies (JURNE); incorporation is not asserted. The inspected repository contains marketing, explanatory settlement and waitlist functionality. That work does not establish transport licensing, live ride fulfilment, token issuance or settlement. The accompanying model uses synthetic local records. A registration is not a verified driver, an active rider or revenue.

2. Participation with clear responsibilities

The recommended first pilot is a technology-service arrangement with one independently licensed London private-hire operator. That operator would genuinely accept the booking and enter the passenger contract; JURNE would provide agreed software and network services. This is a design recommendation for specialist review, not a conclusion that every proposed activity falls outside operator licensing. The booking interface must identify the contracting operator before confirmation, including the relevant terms, support route and receipt issuer.

The alternative is for JURNE itself to become the licensed booking operator, accepting the obligations and costs attached to that role. A partner cannot simply lend its licence to a separate business that is in substance accepting bookings. TfL's published operator guidance requires the appropriate licence and addresses the contractual obligations of the London private-hire operator accepting a booking. The final operating model must be assessed against what each participant actually does. [9]

London taxis need a distinct admission and product path. Their street-hail, rank and fare arrangements must not be represented as identical to private-hire pre-booking. A future taxi integration would preserve the applicable taxi rules and explain the service being booked. The initial private-hire pilot should not imply that all taxis or taxi operators are already eligible on the same terms. [10]

Admission would check licences, insurance, service capability, responsible contacts, integration security and commercial agreement. Standards would cover truthful availability, cancellation behaviour, accessibility, complaints, settlement evidence and reward acceptance. Material failures could suspend new bookings or issuance while an identified reviewer considers an appeal. Emergency safety intervention would not wait for a community ballot.

Offboarding requires an agreed run-off plan. Existing bookings, driver pay, disputed refunds, accepted redemptions and outstanding programme obligations must remain assigned to responsible parties. New rewards should stop before an operator's funding runs out. Programme terms should protect accrued benefits through continued fulfilment, a funded alternative or an agreed remedy, subject to applicable rights. Suspension or departure must not silently erase the financial ledger.

3. The passenger and driver experience

A rider would receive a GBP fare, the contracting operator's identity and material conditions before booking. Familiar card and supported device-payment methods are the intended default. Optional supported stablecoin payment would be a separate choice with an asset, network, quoted amount, expiry and refund explanation. A card-paying passenger should not need to acquire the JURNE network token or understand escrow to travel.

After an eligible completed journey, the account could show a points lot with its value in programme benefits, expiry and applicable operators. The passenger chooses a qualifying discount at checkout. The full funding split should remain clear: an example £20 journey might be paid with £19 from the rider and £1 from the programme. The reward changes the sources of payment, not the agreed basis on which that journey's driver compensation is calculated.

Driver earnings would accumulate separately from points. The intended settlement direction is USDC on Solana, with pending and available amounts distinguished and GBP estimates clearly identified. Circle describes USDC as dollar-denominated and redeemable for US dollars subject to its terms. Direct redemption depends on eligibility and a suitable Circle account; holding USDC does not by itself create a bank cash-out service. [7][8]

Daily-request cash-outs to a bank, or transfers to a compatible supported wallet, are proposed choices. The driver should see the applicable conversion quote, deductions, transfer fee and expected processing conditions before confirming. Bank receipt depends on provider processing, checks and banking arrangements. There is no promise of instant banking or free conversion. Volatile network tokens must not substitute for earned compensation, and neither points expiry nor a network-token burn may remove a driver's earned money.

The intended points experience is an ordinary recoverable account rather than mandatory self-custody. That simplicity creates responsibilities: identity and recovery controls, protection against account takeover, access logs, provider selection and a clear explanation of who can move assets. Embedded wallet software would not solve custody, legal accountability or recovery by itself. If a rider chooses an external wallet, the product must explain its different recovery and erroneous-transfer risks without making that choice a condition of travel.

4. Architecture and the case for Solana

Dispatch, precise location, passenger and driver identity, licensing checks, customer support and payment orchestration belong off-chain in this proposal. They require restricted access, correction, deletion and low-latency operations. The proposed chain layer has a narrower role: programme token inventory, controlled escrow, redemption authorisation and shared settlement-state commitments. Personal identities and trip coordinates would not be written to a public ledger.

Solana offers a common execution environment and token-account model that independent participants could inspect through their own infrastructure. Its documentation distinguishes a mint, which records supply and authority, from accounts holding units of that mint. This provides building blocks for the proposed authorisation inventory; it does not create the programme's legal rights or cash backing. [1] The separate, unmodified Solana mark identifies proposed infrastructure, not sponsorship or endorsement. [17]

A programme record would identify the rule version, admitted operators, controlled escrow, issuance limit and authorised roles. Lot records would link an opaque reference to the quantity of points, redemption value, expiry, funding source and token allocation. Reservation and payable records would track accepted obligations. The privacy design must decide which of these records are public, permissioned or represented by carefully designed commitments; even pseudonymous activity can reveal commercial relationships.

The central alternative is credible and should be costed. Retaining the token layer should require measured improvements: fewer unresolved inter-operator disputes, easier independent reconciliation, reduced adapter work or useful portability across genuinely independent services. Transaction volume alone is not that evidence. If these benefits fail to exceed the additional operational burden, the architecture should be revised before production issuance, while preserving the founder's proposed token-based model for honest comparison.

Solana transactions execute their on-chain instructions together or revert; failed execution can still incur fees. That atomic boundary does not include card capture or a bank payout. [6] A settlement adapter therefore needs durable pending states, idempotency and reconciliation. Transaction fees, account funding, RPC access, monitoring and key management remain costs even if hidden from riders. Provider failure must leave an intelligible obligation rather than a fabricated success. [15]

5. Three instruments, three different jobs

The programme would use network-token units underneath consumer points. Their role is specific: issuance requires a sufficient allocation of those units into controlled escrow as well as sufficient settled reward funding. The allocation limits the programme's authorised activity and supplies a shared record of what has been committed and consumed. It is not the asset paying for the passenger's GBP discount.

Who buys or receives tokens? Under the reference design, an identified programme authority would allocate a bounded initial inventory to admitted operator programmes under recorded rules. Additional issuance would require separately approved authority and limits, with reconciliation of the resulting supply. Operators might access the service through a GBP or USDC adapter that handles permissions and discloses its fee. Riders and drivers would not have to speculate or buy tokens to travel or work.

What creates demand? Access to useful shared rewards and operator services is a candidate source of demand for authorisation capacity. An allocation provided freely, or recycled, does not itself create recurring market-buy demand. Burning units does not prove an economic buyer exists. The pilot must establish willingness to use and pay for the underlying service before making any claim about a token market.

What remains undecided? A bounded operator-network instrument and an externally transferable token are materially different designs. A public market would add price, liquidity, distribution, promotion and market-conduct questions. This paper fixes neither a supply cap nor emissions schedule, mint/upgrade authority, sale mechanism or legal classification. It introduces no ticker, exchange listing, vesting promise or yield. Possession and participation create only the rights actually documented in enforceable arrangements, not an implied share of JURNE.

6. Fund, earn, redeem and reconcile

The reference programme starts with settled operator contributions held through an agreed arrangement. An authorised administrator records eligible liquid funds, a selected fee/risk buffer and available token inventory. A completed, verified eligible event can issue a points lot only when both spare funding and token allocation exist. Card authorisation, an unpaid sponsor promise or a high token valuation is not settled programme funding.

The synthetic fixture begins with £10 programme cash and 1,000 network-token units. One event issues 100 points representing £1 of discount and moves 100 units from available inventory into escrow. Cash remains £10; £1 is committed. Available token inventory is 900, locked inventory is 100 and total supply remains 1,000. This programme mapping is an authorisation rule, not a GBP peg or market price for the token.

When the rider chooses an eligible £1 benefit with Operator B, the service reserves the earliest-expiring available points. The example ride's £20 funding comprises £19 from the rider and £1 due from the programme. Fulfilment moves the £1 obligation from outstanding points into a payable owed to B. It does not release the cash, create a second £1 obligation, or reduce the driver-compensation basis. Actual voucher and VAT treatment needs separate accounting review.

Only confirmed reimbursement makes the payable settled. The fixture then has £9 programme cash, 100 redeemed points and a burn of 100 controlled escrow units, leaving total token supply of 900. A failed or ambiguous external payment leaves the payable outstanding and backed. Retry uses the same obligation identity and a reconciled payment reference, so repeated requests cannot create duplicate payments. A submission acknowledgement is not sufficient evidence of receipt.

The unused-expiry branch has a different outcome: £10 cash remains, the £1 commitment is released, 100 points expire and the associated 100 controlled units are burned. No new pound appears and no profit message is justified. Accounting recognition of unused benefits depends on the actual obligations and applicable policy. Fresh rewards still need fresh eligible events, available authorisation inventory and uncommitted funding; expiry is not permission for uncontrolled reissuance.

What funds benefits? Settled operator contributions, an affordable JURNE budget or an explicitly funded sponsor allocation. Driver earnings are excluded from programme reserves. What if an externally transferable token loses 80% of its hypothetical market value? In this GBP-funded fixture the £1 entitlement and driver compensation remain unchanged. That separation is useful but not complete protection: missing cash, insolvent providers, inaccessible custody or FX losses can still create a shortfall. The model exposes those failures and prevents treating token sales as an assumed rescue.

7. Expiry, refunds and controlled burning

The founder's “mined/demined” idea is expressed here as verified-contribution issuance and scheduled entitlement expiry, not proof-of-work mining. An eligible event may let a rider earn points; a separate authorised operation may issue or mint network inventory. A point is redeemed, expires or is validly reversed. A token is burned. These are related records rather than interchangeable words.

Every lot keeps its original programme version and expiry. Redemption consumes the earliest-expiring eligible amount first, with a deterministic tie-break by lot identifier. Partial redemption leaves the rest of that lot intact. At the expiry boundary, unreserved points are ineligible for a new claim even if housekeeping has not run. A live reservation cannot also be spent or expired. The local fixture uses 30-day points lots and a 15-minute reservation timeout; these are demonstration terms, not adopted launch rules. Each reservation has its fixed timeout, after which an unfulfilled reservation is released; any already-expired underlying entitlement then expires rather than becoming spendable again.

An expiry timestamp does not execute a transaction. The intended programme must reject stale claims at use time, while an authorised keeper later records expiry and burns the associated controlled allocation. If the keeper fails, stale points remain unspendable and the accounting continues to recognise the unreconciled allocation until retry succeeds. Monitoring must distinguish logical expiry from completed housekeeping. Token-2022 is not a universal automatic per-lot expiry switch. [3]

Ordinary fungible balances do not carry each unit's earning date. The reference design therefore places lot accounting in explicit programme state, with an off-chain private entitlement ledger and carefully specified commitments where needed. A future implementation must reconcile these representations. A bare token balance cannot prove which lots remain valid or that cash exists. Optional membership credentials using a NonTransferable mint would be separate from any transferable network-token mint. [1][4]

A cancelled originating ride reverses only unused rewards associated with that event, using recorded terms. Reserved or already-fulfilled benefits require a separate cancellation or dispute resolution; they cannot be silently clawed back. A cancelled redemption releases its unfulfilled reservation according to the expiry rules. Once reimbursement has occurred, a refund needs a linked compensating record and confirmed returned funds before restoring any benefit. Unrelated earned cash never enters these operations.

Burn authority is limited to programme-controlled escrow or properly authorised holder/delegate balances. Solana's burn instructions reduce the token account balance and mint supply; the documented owner/delegate controls must be respected. [2] The proposal does not grant an undisclosed power to confiscate arbitrary holders' units. Token supply reduction cannot by itself stabilise a price, create valuable demand or extinguish a contractual obligation.

8. Unit economics that include the operator

The business must fund the whole journey. Passenger receipts first need a consistent treatment of refunds and applicable taxes. The resulting revenue must cover driver entitlement, operator compensation, JURNE's service charge, payment and FX costs, support, fraud/risk and any rewards contribution. The independent operator cannot be omitted from the allocation or paid from a remainder already promised elsewhere. Network-token issuance contributes no cash to this reconciliation.

An illustrative £24 VAT-inclusive principal fare at a 20% VAT rate leaves £20 before other costs: £4 is output VAT, before considering any permitted input-tax recovery. If driver entitlement is £14, operator compensation £2, JURNE service income £1, payment/FX costs £0.70, support/risk £1 and rewards £0.30, £1 remains as the contracting service’s residual contribution before any unallocated fixed costs and tax. These are transparent synthetic inputs, not proposed tariffs or margin forecasts. A different contractual, tax or driver-cost basis changes the result. [19]

Finance Act 2026 section 82 enacts the change described in HMRC's Revenue and Customs Brief 8 (2025): for relevant supplies from 2 January 2026, the Tour Operators' Margin Scheme no longer applies to supplies of taxi and private-hire journeys except relevant supplies with certain other travel services. A low-margin arrangement should not be assumed to make VAT disappear. Whether a particular party is principal or agent, its registration position and the treatment of vouchers, subsidies and operator services require fact-specific review. [11][18]

The comparison with established services should include like-for-like booked journeys and the same tax, support, insurance, payment and acquisition assumptions. JURNE has not established a lower total cost per completed ride. The pilot should separately measure cost per booking, failed dispatch, completed journey and working driver-hour. Automation savings must include human escalation, model error and monitoring costs; shared infrastructure savings must include integration and reconciliation overhead.

Operators need a reason to join beyond a technical badge: additional profitable demand, a predictable service charge, preserved customer-service identity and fair reimbursement. Rewards should be tested against incremental repeat travel rather than total rewarded volume. If the programme mostly discounts journeys that would have happened anyway, it is a cost without corresponding growth. Unspent contributions and unused points need a documented financial policy; neither is automatically distributable income.

9. Participation, security and accountable control

Driver participation is intended to follow one eligible verified driver, one vote. Token wealth must not buy additional votes. Proposed eligibility uses current admission, one-person checks and a published status date. Ballots should cover defined priorities and service experience, with a stated quorum, voting window, conflict disclosures and a way to challenge eligibility or counting. Failure to reach quorum should return the question to accountable management rather than manufacture consent.

An operator forum would address integration standards, commercial interoperability and common service rules. Service management remains responsible for safety, statutory duties, reserves and incident response. Votes cannot cancel accrued entitlements or override legal obligations. Rule changes need notice, versioning and explicit treatment of existing lots; changing future terms must not silently rewrite a promise already earned.

The control model separates authorities for admission, minting, programme configuration, settlement confirmation and recovery. High-impact changes should require independent approval, audit trails and proportionate delay, with narrowly scoped emergency suspension. Supply limits and issuance ceilings need machine enforcement as well as governance. A compromised administrator must not be able to mint capacity, invent cash evidence and approve withdrawals without another control intervening.

Threats include fake rides, duplicate identities, operator collusion, replayed events, double redemption and fabricated fulfilment. Controls proposed for testing include stable event identifiers, eligibility checks, velocity limits, independent payment evidence and reconciliation by counterparty. A malicious pair of operators could fabricate both sides of an exchange; shared records improve inspectability but do not prove a passenger travelled. Incentives must avoid rewarding activity that is cheap to forge.

Outages and insolvency need financial as well as technical recovery. Expired FX quotes must be refreshed before acceptance. A chain or RPC outage should prevent new promises that cannot be safely recorded, while support explains pending states. Stablecoin depegging, issuer restrictions and inaccessible providers remain risks. Cash commitments should be reconciled with genuinely available funds, and a shortfall should stop new issuance while existing claims receive an explicit resolution process.

Agents and AI may summarise exceptions, propose responses and prepare reconciliations. They should not independently change tariffs, reserve policy, signing permissions or withdrawal destinations. Personal identities and precise locations stay off-chain. A public hash of a guessable email or trip reference is not automatically anonymous; commitments require a threat model covering correlation, dictionary attacks, access and retention. Privacy is an architectural duty, not a label attached to cryptography.

10. Publication and regulatory boundaries

This paper explains a design and does not invite anyone to buy a token. It contains no purchase facility, investment waitlist, airdrop-referral incentive or claimed appreciation from ride volume. The ordinary rider/driver waitlist remains a separate product flow. Publishing an explanatory page does not settle the permission to issue or market an asset; a footer saying “not financial advice” would not create that permission.

UK financial-promotion rules for qualifying cryptoassets have applied since 8 October 2023. The FCA describes routes for lawful communication and requirements for relevant promotions. Whether a specific JURNE communication or instrument falls within that perimeter depends on its substance. [12] The FCA glossary's qualifying-cryptoasset definition considers fungibility and transferability, with particular limited-use conditions; naming an instrument “points” is not a classification decision. [13]

Payment services and e-money are separate questions. Receiving money, maintaining balances, arranging transfers, issuing redeemable value or providing custody/exchange can each require a different analysis. An open multi-operator programme is not automatically a limited network simply because it serves mobility. The payments/e-money limited-network analysis is distinct from the cryptoasset definition. The pilot needs a documented funds flow, contractual rights and provider responsibilities before concluding that any exclusion applies. [14]

The FCA's published timetable, updated 30 September 2026, describes an expected start of 25 October 2027 for the new cryptoasset regulatory regime. This paper does not treat those future permissions as already in force or assume the timetable cannot change. Existing requirements still need consideration now; commencement and final rules must be checked again before production activity. [16]

Transport licensing, consumer information and redress, tax, data protection, financial promotions, payments/e-money, and crypto custody/exchange should have separate review owners. Evidence for one does not satisfy another. The reserve design needs legal and financial review of ownership, insolvency treatment, segregation and permissible use. Until arrangements are actually established, JURNE must not claim legally safeguarded money, audited reserves or guaranteed backing. Research references identify issuers of source material, not JURNE partners.

11. A pilot built around commercial evidence

Stage one should validate one operator's actual service and settlement process within a controlled area and participant limit. Before accepting a booking, admission, passenger contracting, provider roles, support, cash-out procedures and reward funding must be workable. Acceptance criteria include reconciling every completed journey to its receipts, deductions and driver entitlement; demonstrating a funded reward; and resolving a cancellation without losing an accrued claim. Local model tests are preparation for this stage, not its completion.

Stage two should add a genuinely independent operator and demonstrate a benefit earned with one being fulfilled by the other. The test includes a delayed reimbursement, duplicate callback, disputed fulfilment and operator exit. Both operators should independently reconcile the same obligations. No live expansion should rely on a simulated success, and participant numbers should grow only when financial reconciliation and service outcomes remain acceptable.

The potential ecosystem contribution is practical: versioned reward-lot schemas, operator adapters, reconciliation formats, authority patterns and portable test fixtures. Publication and licensing choices remain separate; this repository is not described as open source under an unverified licence. Reusable work should follow validated operator needs rather than a promise to publish every component.

The next resources should be milestone-based: transport and financial-perimeter review; a real operator integration; accounting and reserve design; adversarial security testing; and measured operational support. No funding commitment, partnership or launch date is asserted. Success means useful journeys, properly funded benefits and reliable obligations, not registrations or token transactions standing in for commercial results.

12. Technical appendix and open decisions

Accounting identities

• Current token supply = initial supply + subsequent minting − burns.
• Current token supply = all current holdings, including available inventory and escrow. Locked units still exist.
• Points issued = available + reserved + redeemed + expired + validly reversed points.
• Eligible liquid programme funding ≥ outstanding reward obligations + unsettled operator payables + selected fee/risk buffer.

The last identity is a required coverage control, not proof that a provider will remain solvent. Moving a fulfilled claim from points obligations to an operator payable must neither free its backing nor count it twice. A settled payment reduces cash and its payable together. A housekeeping burn changes token supply but not cash. An expired unused benefit releases its commitment only according to the programme rules. All amounts in the model use integer pence and integer point/token units; production multi-currency arithmetic needs explicit precision and rounding rules.

Proposed interfaces and state

Future interfaces would include admitOperator, recordFunding, issueLot, reserveRedemption, releaseReservation, confirmFulfilment, recordSettlement, expireLot and reverseUnusedReward. Each request requires an operation identity, programme version, authorisation and expected prior state. Evidence from an external provider must be checked before recordSettlement is allowed to complete. A replay returns the previous result; a conflicting payload under the same identity is rejected. No deployed programme address, transaction signature or audit is asserted by these names.

The reference state distinguishes available, reserved, fulfilled-awaiting-payment and terminal outcomes. For conservation reporting, fulfilled quantities remain accounted for with the reserved claim until settlement, while their financial obligation is represented only by the payable. Reservation timeout applies before fulfilment; it cannot erase an accepted payable. A settlement adapter needs durable intent, attempt and confirmed-result records to survive crashes between an external transfer and internal acknowledgement.

A future Solana implementation could hold controlled inventory and escrow in programme-derived accounts, with separate mint and upgrade authorities. Transfer hooks can invoke custom checks during transfers, but require a deliberately implemented programme and compatibility review; they do not replace the reward ledger or cash evidence. [5] Extension choices should follow reviewed requirements rather than combining conflicting capabilities. No arbitrary holder-burn power is proposed.

Unresolved decisions and limits

Before production, decide the legal operator model, admission contracts, reward expiry and appeals, fee/risk buffer, reserve owner and custody structure, eligibility evidence, settlement currency, provider failure remedies, public-data threat model, token transferability, mint and upgrade authority, supply limits and security acceptance criteria. The synthetic £10 fixture selects no commercial reserve ratio. Its GBP funding deliberately avoids an FX assumption; a USDC-funded GBP obligation would need conservative valuation and liquidity management.

This version demonstrates internal accounting logic and a proposed service structure. It does not prove demand, licensing, legal classification, solvency, audited security or live settlement. The token layer must earn its complexity by helping independent operators coordinate useful services. The founder's thesis remains testable: ordinary people use familiar journeys and rewards, while the infrastructure underneath shares authorisation and records without making speculative token value responsible for driver pay or promised benefits.

Glossary