OrangeTopia: from lifestyle game to Hanwha's data-to-earn platform
Repositioning a live, underused mobile asset into a consented consumer-data engine — a digital companion that grows on finance, health and lifestyle data, and feeds cross-sell across Hanwha's Indonesian subsidiaries.
Scope: Hanwha Life Insurance Indonesia only · Trust layer: minimal anchoring — hashes on-chain, raw data in cloud/IPFS · Chain: existing public network — Polygon / Base / Kaia, finalised in Phase 0 · Timeline: Phase 0 scoping 3–4 weeks → MVP ~10–14 weeks · Commercials: hour-level WBS follows the Phase-0 audit
Everything else in this document is the longer-term vision the POC grows into. Elements marked Future vision are deliberately beyond POC scope.
Not a dead app — an unpositioned one
OrangeTopia already collects personal data with consent infrastructure, runs a walk-to-reward mechanic and serves insurance content through NPCs. The foundation exists; it points in no particular direction.
Data-to-earn with a digital companion
The orange mascot becomes a reactive companion that grows as users connect data sources — steps, spending, health signals. AI agents turn the profile into personal insight; a trust layer makes every consent provable.
One consented profile, group-wide
A unified finance + health + lifestyle profile per user, collected under Indonesian PDP rules, powering targeted offers from Hanwha Life — and, as the future vision, across the wider group including Nobu Bank; scoring from 2027.
Level 1 — now
Grow an engaged user base and collect consented financial, health and lifestyle data through the reworked app. Value is measured in data-complete profiles, not raw MAU. Rewards are funded by ecosystem margin — deliberately not by a consumer token (see the on-chain evidence in Market evidence).
Level 2 — from 2027
Credit and customer scoring built on the accumulated profiles. Every consent event recorded now is designed to be provable later — the trust layer turns today's collection into tomorrow's audit-ready scoring input.
| Verified from the public store listing | What it means for scope |
|---|---|
| Category: Lifestyle, not Games | The store positioning already matches the pivot — no category migration needed |
| Last updated March 2026 | The app is maintained, not abandoned — this is a repositioning, not a resurrection |
| 10K+ installs, ~13k users over 4 years, MAU ~1k; rating 3.2 | A reach problem, not a product-death problem — solved by the distribution rail in Economics, not by more features |
| Walk mechanic live: steps → daily-mission rewards | The data-to-earn primitive is already shipped — we extend it to health APIs and rPPG rather than invent it |
| Metaverse NPCs already serve insurance information | The cross-sell narrative is already in the UX — an anchor to build on, not a new concept to sell to users |
| Points → items / e-vouchers already implemented | Reward rails exist; the work is tier-gating them to consent depth, not building them |
| Data safety: already collects Personal info, shares with third parties, encrypted in transit, supports deletion requests | Collection and consent plumbing partly exists — codebase access (see Open decisions) will confirm how much scope this saves |
Source: Google Play listing, verified July 2026. The codebase audit in Phase 0 turns each of these into a confirmed scope saving or a confirmed rebuild item.
Market evidence
Two research passes across ~25 comparable products, cross-checked with on-chain data. The pattern is unambiguous: data-driven loops funded by ecosystem margin scale; token-funded loops collapse.
Alipay Ant Forest
Data → growing entity → tangible reward, inside a fintech super-app. Hundreds of millions of users, planetary scale — and no blockchain, no token.
Public reports; figures to be footnoted in final version
FiNC (Japan)
A mascot-coach fed by health data — sleep, steps, weight, nutrition. 11M+ downloads, Japan's leading health app. The closest mascot-data-reward loop in Asia.
Ping An
251M retail customers; health + insurance data with an AI layer produced a measured ~4 p.p. upsell uplift. The proven case of data + AI + insurer distribution converting into cross-sell.
AIA Vitality
Insurer-funded rewards: premium discounts paid for by better claims and persistency, not by emissions. The actuarial template for OrangeTopia's reward economics.
Pokémon Sleep
Sleep biometrics feeding a companion creature, at tens-of-millions scale. Proof that "your body data grows a character" is a mainstream mechanic, not a crypto niche.
Vana
User-owned data, proof-of-contribution, consent attribution. We adopt its architecture pattern for the trust layer — explicitly not its token model.
Method. Monthly distinct receiving owners (active wallets) per token on the main chain (Solana), Jan 2022 – Jun 2026, verified on-chain via Dune decoded transfers against canonical mint addresses. STEPN's BNB leg shows the same shape (≈ −98%), so the pattern is multi-chain. Wallets ≠ unique humans; the robust signal is the trend, not absolute counts. Implication: token incentives buy a spike, not a habit — a durable loop must be funded by recurring utility or business margin.
Korean bank metaverses
KB Kookmin, Hana, NH, Woori, Shinhan — meaningful pilots 2021–2023, shut down or deprioritised by 2024–2026. Brand engagement never converted into durable financial usage. Including early metaverse experiments across the wider industry, the lesson is consistent: metaverse-first fails; data-first with an optional game layer works.
What this rules out — as an evidence-based default, not an ideology
No consumer incentive token, no token-funded rewards, no metaverse-first framing. The position is defensible rather than dogmatic: a token is not a guarantee of engagement — two independent projects lost 97–99% of active wallets proving it — so the burden of proof sits with whoever proposes one. Regulated instrument tokenization (insurance and reinsurance products, Phase 3) is a different question entirely, and stays on the roadmap.
GoTo / GoPay
Fintech MTU up 33% YoY to 27.5M; loan book Rp9.9T (+59%) explicitly attributed to data-driven risk. Behavioural data converting into lending economics, in this market.
Grab
50M+ monthly transacting users across SEA. Everyday behavioural exhaust monetised through multi-product cross-sell, with AI as an operational layer — not the product thesis.
Rey / ReyFit
Indonesian insurtech: health targets → daily rewards, funded by insurance membership. Small, but the loop OrangeTopia scales — already validated in Indonesia.
Binah.ai — rPPG
Vital signs from a 30–60s selfie video. Removes the wearables barrier for Indonesia's budget-phone audience — health data capture with the camera users already have.
PDP & OJK
Health and financial data are "specific personal data" — explicit consent, deletion rights, heightened governance. OJK's aggregation regime carves out group-internal use: OrangeTopia is positioned as group-internal and consented by design, not as a neutral aggregator.
AstraPay / Astra
A diversified conglomerate using one app as the control point for in-group cross-sell — the closest structural mirror of Hanwha's Indonesian position.
Regulatory fit — requirement to design decision
| Regulatory requirement | Design answer in this proposal |
|---|---|
| PDP: health and financial data are "specific personal data" — explicit consent per category | Consent-as-progression: each companion tier is an explicit, per-category consent event — recorded as a provable commitment (Vision → tiers) |
| PDP: right to erasure | Crypto-shredding: raw data off-chain under user keys; destroying the key makes data unrecoverable while audit commitments stay intact (Trust layer) |
| PDP: heightened governance for large-scale sensitive processing and systematic monitoring | PII anonymisation proxy before any LLM call, k-anonymity at profiling level, end-to-end audit trail anchored in the trust layer (Architecture) |
| OJK 2025 aggregation regime: licensing for financial aggregators — with a carve-out for group-internal aggregation | OrangeTopia is positioned as group-internal and consented by design, not a neutral aggregator; the legal boundary is designed up front, not retrofitted |
| Data localisation posture (to be confirmed — see Open decisions) | Private DA options keep all data availability inside Indonesia; the architecture supports either answer |
Regulation here is not a compliance checkbox appended at the end — each requirement maps to a product or architecture decision that also improves the user proposition.
| Capability | Ant Forest | FiNC | Ping An | Vitality / Rey | STEPN class | OrangeTopia |
|---|---|---|---|---|---|---|
| Data-fed companion / twin | partial | yes | partial | no | yes | yes |
| Insurer / bank distribution | fintech | no | yes | yes | no | yes — group-owned |
| Finance + health + lifestyle in one profile | no | health only | partial | health only | no | yes |
| Provable consent / trust layer | no | no | no | no | token, decorative | yes — infrastructure |
| Reward funding | ecosystem | e-commerce | insurer margin | underwriting | token emissions | ecosystem + underwriting |
The white space
No product in either research pass combines insurer distribution, a data-fed companion and a provable-consent trust layer. OrangeTopia occupies an empty cell — while every individual mechanic it uses is already proven at scale by someone else.
Framed as managed risk
This is category-defining, not experimental: the combination is new, the components are not. Each mechanic carries a named, working reference — and each failure mode carries a named, documented graveyard case.
| Case | Market | Twin | Game | Chain | AI | Status / traction |
|---|
✓ strong · ± partial · — absent. Axes: user twin/avatar · game/metaverse shell · real blockchain component · AI layer. Click any row for collected data, insurer link, full traction and the case's role in this proposal.
Method
Two structured research iterations: a global landscape pass (digital twins, move/data-to-earn, insurer wellness ecosystems) and an Indonesia/SEA gap-closure pass (super-apps, insurtech, regulation, Korean bank metaverses). Move-to-earn decline was not taken from reports — it was measured directly on-chain via decoded token transfers against canonical mint addresses, on the main chain with an independent EVM cross-check.
Provenance — stated honestly
Traction for private companies partly rests on store listings and corporate statements, and is tagged as such per case. Korean metaverse shutdowns are partly inferred from absence of updates plus industry reporting. On-chain figures are verified. The one conclusion stable across both passes: no production product combines insurer distribution, a data-fed twin and a provable-consent trust layer.
Vision — the loop
One self-reinforcing cycle. Every element below is clickable — each opens the reasoning, the reference case behind it, and what we build.
Consent as progression
Indonesian PDP law requires explicit consent per category of specific personal data. We turn that constraint into the game mechanic itself: each connected source levels the companion up — and each level-up is a recorded, provable consent event.
Companion, not a literal twin
The proven pattern is a reactive creature fed by your data (FiNC-chan, Pokémon Sleep, Ant Forest's tree) — not "an avatar that is literally you". Lower conceptual risk, same data engine underneath: a stateful representation of health, finance and behaviour.
Insight is the hook
The strongest motivator at every benchmark: the more you share, the sharper your personal health and financial guidance. Points and vouchers support the loop; they are not its centre.
Reward ranking
1 — personalised insight · 2 — ecosystem benefits (premium discounts, Nobu perks) · 3 — events & access · 4 — digital content · 5 — direct points, deliberately minimised. No consumer token — by evidence, as a defensible default.
What flows back to the user — reciprocity as the growth engine
Value within one session
A platform that only serves the insurer is a liability users tolerate; one that visibly serves the user first is a product users grow. The operating standard: every data point contributed returns value — an insight, a nudge, a saving — within the same session. Insights are descriptive, never diagnostic; every nudge carries "why am I seeing this"; mood data never drives offers directly.
The user data wallet
From "we hold your data" to "you carry your data": verified slices portable to a bank, clinic or another group affiliate — as a full signed attribute, a selective disclosure (two fields of nine, signature still valid), or a single yes/no proof. Every share generates a revocable receipt with an expiry; the 2027 cross-affiliate story is this wallet's native use case.
The value receipt
A monthly statement — "your data earned you X points, 4 insights and this coverage fix" — makes reciprocity legible to the user and gives HQ a measurable "user value delivered" KPI. Insights that end in a question ("irregular sleep — want a two-week sleep quest at double rewards?") are the product's core flywheel mechanic.
Economics
A live model, not a promise. Drag the assumptions — every figure marked as an assumption is a parameter Hanwha can replace with internal data; the framework holds.
Distribution — why this time is different Future vision
For the POC, distribution runs on Hanwha Life Indonesia channels — the agent network and the existing policyholder base. The group-scale rail below is the future vision this platform grows into: OrangeTopia v1 reached 13k users in four years because it had no distribution channel; the group now controls a bank.
The rail is already being built
Hanwha Life closed a 40% stake in Nobu Bank with management rights in June 2025, and Hanwha Life insurance products are distributed to Nobu customers since Q4 2025. OrangeTopia does not create the group cross-sell motion — it plugs into one that is already moving.
Upside, not baseline: the Lippo ecosystem
Nobu's heritage network — 60 malls, Matahari retail, Siloam (Indonesia's largest hospital group, a natural health-data partner). Access after the change of control is a partnership question, so the model treats all of it strictly as upside; the base scenarios stand on Nobu alone.
Reward budget — derived three independent ways
1 · Vitality anchor (top-down)
In developed markets users pay $96–150/yr for wellness membership, and premium discounts are funded from claims and persistency gains. PPP-adjusted for Indonesia, the perceived-value ceiling lands at $20–40/yr per engaged user.
2 · CAC parity (bottom-up)
Fintech installs in SEA cost $1–3; an active, funded customer costs multiples more. A consented, data-complete profile is worth more than an install — $5–15/yr in rewards is justified as marketing substitution alone.
3 · Self-funding check
Value per data-complete profile: Rp100–200k/yr (cross-sell + bank products + persistency). A sustainable reward budget at 30–50% of that: Rp50–100k/yr. All three methods converge.
| User tier | Marginal reward cost | Face value to user | Funded by |
|---|---|---|---|
| Player (no sensitive data) | ≈ 0 | content, companion status | content cost ≈ 0 |
| Partially connected (1–2 sources) | Rp 2–4k / month | Rp 5–10k / month | ecosystem vouchers — face value 2–3× marginal cost |
| Data-complete | Rp 5–10k / month | Rp 15–30k / month | + premium discounts from persistency gains, Nobu benefits |
Why no cash-like rewards
At Indonesian ticket sizes, cash-equivalent rewards do not clear the self-funding bar. The loop works on in-kind ecosystem benefits (voucher face value above marginal cost) and insurance discounts funded from claims/persistency — a quantitative confirmation of the no-token decision, not just a design taste.
Honest position
At MVP horizon this platform is not a profit centre and is not pitched as one. It pays for its own reward loop and builds a consented data asset whose value is realised through bancassurance now and scoring from 2027. The cost of the experiment is bounded and visible above.
Assumptions marked as sliders are planning parameters, to be validated with Hanwha internals: actual Nobu digital MAU, bancassurance ticket sizes, Hanwha Life × Nobu base overlap, and the P&L owner of the reward pool.
Architecture
Based on the full technical deep dive (v4) by the Innowise Blockchain & Data Practice. Most of the processing core is reused from an architecture already designed and validated for Hanwha in previous engagements. Click any component or pipeline layer for its role.
The processing pipeline — eight layers, clickable
Intake sequence: quest / connector / event → intake gate (schema sniff, consent check, device attestation) → anti-fraud pre-screen → BRONZE (raw, immutable, encrypted) → layers above → SILVER → GOLD per-user data graph → insights, rewards, verifiable products.
System map
green — already designed & validated in our prior Hanwha engagements, directly reusable red — net-new build for this project (what exists inside the current OrangeTopia app is confirmed by the Phase-0 audit)
The mobile client fork — decided by evidence, not preference
Option A — rework the existing Unity app
Strip heavy 3D scenes, keep the shell, walk mechanic and reward rails, embed the new data-quest UI. Fastest reuse of shipped mechanics and the store listing; users keep the familiar app. Chooses itself if the Phase-0 audit shows readable code with usable consent and reward modules.
Option B — rebuild on React Native
New lightweight 2D client; smallest app size, best low-end-device performance, a clean codebase Hanwha Life Indonesia can own. Chooses itself if the audit shows opaque or undocumented vendor code. A hybrid path is viable: A for launch continuity, B built in parallel behind the same API, switched cohort by cohort.
The irreducible core — seven decisions made once
Canonical fact model & attribute dictionary · consent receipts on every fact · envelope encryption with per-user keys · record hashing at silver promotion · event schema registry · PII proxy in front of every LLM · append-only bronze. Cheap to do now, ruinous to retrofit — together they make every later upgrade a swap instead of a rebuild.
The scope dial — degrade implementations, never contracts
Every heavy capability (zk-validium, TEE processing, split custody, zkVM proofs, graph databases, fraud ML) has a stable interface and a swappable implementation with a named upgrade trigger. The MVP lands at roughly a quarter of the full build cost while touching none of the seven core decisions.
Trust layer
Honest framing first: the product value lives in data and cross-sell. Blockchain earns its place here only as consent, provenance and audit infrastructure — and one decision determines its entire shape.
Private zk-rollup — validium mode
A private, permissioned perimeter with a cryptographic anchor to a public L1 via validity proofs. Raw data stays off-chain (device / IPFS); only proofs and commitments go on-chain — exactly the data model this project needs.
What it uniquely gives
Privacy-preserving compliance — prove to a regulator that consent was obtained and policy followed, without revealing health or financial data. Crypto-shredding resolves the immutability-vs-erasure conflict under PDP. Multi-zone maps one zone per subsidiary with controlled gates — the group cross-sell architecture, expressed structurally.
Named honestly: the risks
Enterprise zk is a 2024–2026 generation — fewer battle hours than consortium stacks. Infrastructure depends on a specialised partner (prover/DevOps), with production sequencer milestones through late 2026 – early 2027. Mitigation: EVM from day one, phased rollout, anchoring fallback below.
Transparency log + periodic anchoring
Data off-chain (device / IPFS, verifiable credentials); Merkle roots committed periodically. Near-zero operational cost, fastest to MVP, verifiable integrity without running a chain.
What you give up
No on-chain programmability for consent and reward logic, and — without an external anchor — any fully private ledger reduces to a signed log trusted on the operator's word. We say this plainly rather than selling a private chain as something it is not.
Upgrade path preserved
The data model (proofs on-chain, raw data off-chain) is identical in both branches. Starting with anchoring does not burn the validium option — it defers it until the anchor question is settled.
Chain candidates for the POC anchor
Polygon
Lowest anchoring cost with mature, battle-tested tooling and the widest EVM talent pool. The conservative default.
Base
A large consumer and web3-gaming ecosystem with strong institutional backing — a natural fit for a consumer-facing loop.
Kaia Future synergy
IDR stablecoins are already live on Kaia, and the group's banking stream is active there — the strongest future-synergy candidate. Ecosystem sustainability to be verified in Phase 0.
Cost at volume: even hash-only anchoring can accumulate gas at scale — which is why proofs ride a daily Merkle batch: one transaction per day regardless of record volume, with O(log n) inclusion proofs. Final chain selection happens in Phase 0 against cost, finality and ecosystem-sustainability checks.
The full option space — why we narrowed to two branches
Five architectures were evaluated against the actual requirements of this project — sensitive health + finance data under PDP/OJK, multi-subsidiary rollout, non-crypto users. The fork above is the conclusion of this analysis, not a preference.
| Criterion | Public L1/L2 | Own appchain | Consortium (Fabric / Besu) | Private zk-validium | Minimal anchoring |
|---|---|---|---|---|---|
| Data privacy | all metadata public | ⚠ depends | strong | strong + zk proofs | data off-chain |
| Independent immutability anchor | yes | yes | no — own consensus | validity proof on L1 | yes |
| Data sovereignty (PDP / OJK) | no | ⚠ | yes | yes — private DA | yes |
| Right to erasure | no | ⚠ | conflict | crypto-shredding | yes |
| Privacy-preserving compliance | no | no | no | unique capability | no |
| Multi-entity (one zone per subsidiary) | ⚠ | ⚠ | channels | zones + gates | no |
| EVM & talent availability | yes | yes | ⚠ Besu yes / Fabric no | EVM from day one | n/a |
| Token-trap risk | high | ⚠ medium | none | none — gasless AA | none |
| Verdict | Rejected: business-signal leakage, regulatory discomfort, gravity toward a token | Rejected: permanent operational tail, over-engineered for writing proofs | Fallback if a fully internal network is mandated — honestly, a distributed database under operator trust | Recommended — if the external anchor is accepted | Honest minimum and the Phase-1 mode in either branch |
What goes on-chain — in every branch
On-chain
Consent tier events · data fingerprints (hashes) · AI-agent output commitments · marketing/reward records. Small, non-sensitive, provable.
Never on-chain
Raw personal data of any kind. Health and finance data live off-chain under user keys; deletion is real (crypto-shredding), not simulated. And no consumer token — a design default backed by the on-chain evidence in Market evidence, not a prohibition: tokens are simply not a guarantee of engagement, so the consumer loop runs without one. ERC-3643-class tokenization of regulated insurance instruments remains a Phase-3 capability — a different instrument class with a different purpose.
The proof chain — six artifacts
| Artifact | What it proves | When |
|---|---|---|
| Record hash at silver promotion | This exact fact existed, unmodified, at time T — recomputable (a compliance requirement) | Phase 1 |
| Daily Merkle batch — one anchoring transaction per day | Inclusion of any record, at trivial gas cost | Phase 1 |
| Consent receipts | User U consented to scope S at time T — without revealing U or S on-chain; tier progression is itself the audit trail | Phase 1 |
| Verifiable credentials with selective disclosure | "Age over 21", "policyholder in good standing" — without revealing the underlying values | Phase 2 |
| zk-proofs of computation | A risk score or eligibility flag was computed by registered logic over committed inputs — a claims contract consumes the proof, not the data | Phase 3 |
| AI-agent output commitments | Provable AI provenance for every automated insight and reward decision — increasingly demanded by regulators | Phase 1 |
The chain-agnostic trust adapter
A deliberately narrow interface — anchor, verify, consent event, reward record — with adapters for each branch. The core never imports chain SDKs; no linkable identifiers ever cross the adapter (only opaque roots); business logic lives off-chain in every branch. Net effect: the anchor question can stay open through Phase 0–1 without blocking a single line of platform work — answering it later costs an adapter, not an architecture.
Privacy modes — one record, five disclosure levels
Keys and commitments form matching trees (user → domain → attribute → record), so sharing and proving are both subtree operations. The ladder: M0 existence proof only · M1 one true/false bit (ZK predicate) · M2 selective fields · M3 a value re-encrypted to one recipient · M4 a time-boxed domain grant. For the most sensitive domains, custody is split 2-of-3 — the platform alone cannot decrypt medical data; user consent is a cryptographic event, not a database flag.
Verification without disclosure — the predicate catalog
| Predicate | Proves | Consumer | Complexity |
|---|---|---|---|
| age_over(n) | Age ≥ n from a DOB credential | Any age-gated product | Trivial |
| income_band(b) | Verified income within a band | Bank affiliate, underwriting | Low |
| residency(region) | Indonesian residency / province | Regulated products | Low |
| policy_active() | An in-force policy | Partner discounts | Low |
| activity_level(l) | Verified activity above threshold over 90 days | Wellness-linked premium discounts | Medium |
| non_smoker_attested(t) | Consistent attestation over t months | Underwriting | Medium |
| claim_conditions_met(policy) | Private claim evidence satisfies policy terms | Claims smart contract | High — Phase 3 |
| feature_computed_correctly(f) | A gold feature derives from committed inputs via registered logic | HQ audit, reinsurance investors | High — Phase 3 |
The first four ship on standard verifiable credentials alone — no zk-SNARK stack required. This sequencing keeps the PoC honest while the roadmap stays ambitious. Issuer signs over gold facts and anchors commitments; the user's wallet builds proofs locally; the verifier checks signature + anchored commitment + predicate — and learns nothing else.
Wellness-linked premium discount, zero disclosure
A user opts into an active-lifestyle discount. Their 90-day activity aggregate is committed on-chain daily; the wallet builds an activity_level(high) proof over those commitments — raw steps and heart-rate never leave the platform, not even to underwriting. The policy verifies the proof and applies the discount; the decision itself is logged and anchored. A personalised-premium product with provably zero access to raw health data — regulator-friendly and a market first for Indonesia.
Delivery & MVP
Three scope options — pick a starting slice, not a leap of faith. Module effort sizes are indicative (S/M/L); hour-level estimation follows technical scoping of the existing codebase.
What MUST means: not "large" but load-bearing — these are the components without which later components cannot be built; removing one breaks the upgrade path, not just a feature. Options are Phase-1 configurations of the scope dial: implementations degrade, contracts never do — any option upgrades to the full system without schema or API changes. Hour-level WBS and commercial terms follow the Phase-0 audit; this configurator fixes the shape of scope first.
Phasing — capability gates, not date promises
Scope-dial principle: degrade implementations, never contracts. The MVP is roughly a quarter of the full build cost while touching none of the seven irreducible-core decisions. The remaining honest risk is organisational, not architectural: Phase-0 access to the codebase, Nobu API and IT — which is exactly why it is a phase, not an assumption.
Open decisions
Seven client decisions determine the final configuration. Each is stated with why it matters and the default we assume until answered — we are prepared for either branch of every fork.
Experience
Why Innowise for this: the blueprint is already written, the infrastructure partner is already in production, and the recommendations in this proposal are backed by our own on-chain research.
Validated Hanwha blueprint
The multi-agent processing core proposed here was designed and validated in previous Hanwha engagements — orchestration, data preparation, profiling, PII protection, memory. Months of architecture work already done, directly reusable.
Own on-chain research
The move-to-earn evidence in this proposal is not quoted from reports — we measured it ourselves on-chain, across two independent projects and two chains. The same rigour goes into the build.
Not a competitor to your DWH
OrangeTopia is a unified consent and collection layer on top of existing group infrastructure. A warehouse stores data; it does not make consent provable across entities. Complement, not replacement.
Every layer of this platform, already shipped somewhere
| Platform layer proposed here | Where Innowise already shipped it | Evidence |
|---|---|---|
| Medallion lakehouse & cleansing | Data lake for a banking group — bronze/silver/gold, customer-360, NBA/NBO personalisation | Banking-grade delivery, ~10-person team |
| LLM extraction & governed AI access | LLM analytics chatbot — RAG over relational + document stores | The one-generation-earlier twin of the MCP pattern |
| Behavioural personalisation | eCommerce recommendation system on collected user activity | +72% cross-selling |
| Anti-fraud ML, thin-file users | Real-time fraud detection for a US bank — few-shot learning for thin histories | ~5× fraud-risk reduction |
| Churn / lapse early warning | AI churn prediction for a MENA retail bank | 17% of churned clients re-activated |
| Identity assurance | KYC platform — 3D biometrics, document verification | Production KYC/KYB/AML |
| Insurance domain | Insurance web portal — policy lifecycle | 80% of agent work automated |
| Health-data standards | FHIR integration gateway to major EHR systems | Delivered in 3 months |
| Proof-of-data anchoring & tokenization | Blockchain document integrity app · real-estate & diamond tokenization · decentralized banking with wallets, KYC and loyalty | Production chains, regulated-token capability |
Metrics as published by Innowise. Additional directly relevant cases — instant credit scoring for BNPL (alternative behavioural data, thin-file focus), a sub-50 ms real-time fraud defense with a shadow-mode rollout methodology, and GNN-based AML ring detection — are available under NDA. Orangetopia 2.0 is the first time these proven pieces compose into one product.
Selected blockchain delivery track record
Haust Network — live L2
An EVM L2 built end-to-end: lending proved on testnet first, then DEX, wallet, cross-chain messaging and account abstraction — with an AI layer added on top. The same stack family proposed for the validium branch, in production.
Bank transformation & deposit tokenisation
Ongoing work with traditional, regulated banks: public-chain connectivity, private chains for internal processes, and a deposit-tokenisation solution for a state bank — tokenised deposits usable as provable collateral across institutions.
Neobank builds
Multiple neobanks delivered by composing licensed providers — card issuing, account management, payments — into one product. Directly relevant to embedding financial rails behind a consumer app.
AI-agent transaction platform
A multi-agent system where a user states an intent in natural language and agents assemble the transaction — confirmed by the user's own wallet. Shipped as mobile, web and an MCP integration; agents are pluggable and revocable. The closest prior art to OrangeTopia's AI layer.
Appchain, DePIN nodes & hardened comms
A five-chain Polkadot-class network protecting AI messaging for a US client; wallet-controlled physical nodes (pre-configured mini-PCs) with staking rewards; and a satellite-command integrity solution where signed on-chain instructions are cross-checked against the conventional channel to defeat spoofing.
RWA tokenisation with on-chain KYC
Lab-grown diamond tokenisation (US): tokens backed by physically held inventory, secondary-market trading, physical redemption via token burn — and a five-level KYC enforced at contract level, not just in the UI. The reference for consent and eligibility enforced on-chain.
Regulated trust-layer deployments
Defense-sector multi-zone deployment (Switzerland) with full per-country isolation and controlled data-export gates; SheaTrust — EU Digital Product Passport on a permissioned L2. External pattern validation: Apex Group (~$100B tokenised on Polygon CDK), ZKsync Prividium (permissioned validium for regulated workflows). The recommended branch is an industry pattern, not our invention.
Delivery model
Innowise: business analysis, smart contracts, backend, integrations, delivery — 8+ years in blockchain, from smart contracts to full L1/L2 networks. Specialised infrastructure partner covers the prover layer and DevOps for the zk branch. Further references, including work for one of the largest stablecoin issuers, available under NDA.
About Innowise
Global footprint, EU base
Headquarters in Warsaw with offices across Poland, Lithuania, Germany and Georgia; delivery worldwide — with the largest client concentrations in the United States, Asia and the European Union.
Three engagement models
Full-cycle outsourcing (requirements in, working product out), outstaffing (individual specialists or whole teams plugged into your structure), and IT audit & consulting — from code review to deep architectural assessment.
Blockchain practice
The fastest-growing domain in the company: L1/L2 networks, explorers, cross-chain bridges, account abstraction, wallets, DEX and lending builds, RWA and data tokenisation, AI × blockchain platforms.
AI, ML & data science
Multi-agent systems, LLM gateways, data platforms, ML in production — together with blockchain, the two fastest-growing request streams; the processing core of this proposal.
Mobile & product
Native and cross-platform delivery for finance and insurance clients, including lightweight builds for emerging-market devices, backed by dedicated platform teams (250+ specialists on SAP, Salesforce and adjacent platforms) and a large QA and data-analytics bench.
This document is a working draft (v1, July 2026). It contains market benchmark data and planning assumptions; commercial terms are provided separately. Benchmark figures derive from public sources and Innowise on-chain research; assumptions are marked as such throughout.