MERIDIAN GLOBAL FINANCE
Investor view
MERIDIAN GLOBAL FINANCEEverything below is described the way it exists today: in development, tested where noted, and not yet licensed to move real money. That distinction matters more here than anywhere else on this site.
Meridian Global Finance is the holding company. NHWB — New Halcyon World Beit — is the institutional brand pursuing the licences to operate within it. Echelon Chain is the settlement ledger; the Echelon System is the operating layer above it, including the ability to take payments — not yet built, not yet licensed.
A dual-layer design: a private settlement engine that executes transactions and maintains the asset-marker ledger, and a permissioned gateway layer for licensed institutions to connect through. Target network size and fault tolerance:
| Validators (target) | 13 |
|---|---|
| Byzantine tolerance | 4 nodes |
| Consensus | Proof of stake |
| Same-jurisdiction settlement (target) | ~15 sec |
| Cross-regional settlement (target) | ~1–4 hr |
The unit of account is a fixed gold weight, not a fiat peg — deliberately outside the DFSA's stablecoin definition, which covers fiat-referenced tokens only.
| 1 Noble | 0.047424g gold |
|---|---|
| 1 penny | 0.0001976g gold |
| Pennies per Noble | 240 |
| £/$ value | Floats with the gold price |
PAM (Personal Asset Marker): a citizen fund seeded at birth, compounding untouched to 18, then paying a lifelong allowance under a safe-draw rule — citizen draw plus state share can never exceed the fund's actual yield. CAM (Commodity Asset Marker): tokenised everyday assets — property, vehicles, loans — under $500K. SAM (Sovereign Asset Marker): the tier above that, for high-value trusts and sovereign assets, with mandatory dual sign-off on any amendment.
Echelon Payment Centre is the registration layer in front of the Echelon System: subscribers register for network access, and merchants register their details and compliance attestations. It is registration and compliance intake only — no money moves through it. That capability waits for the Echelon System, which is not yet built or licensed.
There is a lot here. Rather than working through it in order, pick the route that matches why you are looking. Each is a sequence, not a menu.
Watch one payment run end to end, then see the fraud controls that sit around it. That is the shortest honest account of what this is.
1. A card payment, Dubai to London → — press Take payment and watch the eight steps.
2. Institutional settlement → — look at the token lookup and the freezing order panel.
3. Revenue and unit economics → — drive the model with your own assumptions.
Start by trying to break it. The verification page exists specifically so you do not have to take anything on trust.
1. Verify the base-33 layer → — run the self-tests, then inject a fault and confirm it is caught.
2. The double-entry ledger → — attempt an unbalanced posting and watch it refused.
3. Technical view with the chain → — tamper with a committed block and verify the chain.
4. The ESTC codex → — the code ranges, checked against real SWIFT message categories.
The order of operations is the argument. Compliance runs before money moves, and every control leaves a record.
1. Institutional settlement → — note that Send stays disabled until KYC and AML clear, and re-locks if anything changes.
2. The same page’s freezing order panel — court-order gated, 7 days with one extension to a hard 14-day maximum, actioned through the hub whose jurisdiction applies.
3. The banking app → — card controls, including a gambling block on by default, each written to the ledger.
4. The route to authorisation section further down this page.
Every page carries an honesty panel setting out what is real and what is simulated. Those are worth reading — they are where the limits of this demonstration are stated plainly rather than discovered.
A browser-based demonstrator of the ledger concept, and a tested backend reference implementation behind it. Neither is the production network — both are honest about that on their own terms.
The unusual part of this architecture isn't decoration — it solves a specific, well-known class of financial software bug. Here's the reasoning, and where to go and check each claim yourself.
Floating-point arithmetic cannot represent most decimal fractions exactly. In finance this produces rounding drift — the reason serious systems never store money as a decimal. Bitcoin counts whole satoshis; card networks and core banking systems count whole cents or sub-cent units, as integers. Our ledger does the same thing: every amount is an exact integer count of hay-pennies (GBP 0.005), and pounds, pence, and coin breakdowns are all derived from that integer for display only. Integer arithmetic is exact, so the ledger reconciles with zero rounding anywhere.
Base-33 makes this discipline mandatory rather than optional. 33 factors as 3 × 11, so a fraction only terminates cleanly in base-33 if its reduced denominator's prime factors are 3 and/or 11 — which halves, quarters, tenths and hundredths are not. There is therefore no way to quietly represent "half a penny" as a base-33 fraction and hope it rounds nicely. The system has to count whole smallest-units, because the alternative visibly doesn't work. A constraint that makes the wrong approach impossible is worth more than a convention that merely discourages it.
Some operations — interest, dividend splits, FX — genuinely do land between smallest units. Rather than absorbing that silently, the ledger routes every such case through a single apportionment function using the largest-remainder method, so the parts always sum back to exactly the original total. Not a hay-penny lost, not one invented, and the remainder lands on a real auditable line. A ledger that rounds quietly is worse than one that refuses to round at all; this one does neither.
To be precise about what does the work here, since it matters under technical review: the base-33 requirement enforces the unit discipline. What enforces integrity is separate and conventional — strict integer-only input validation, a double-entry rule that refuses any transaction whose debits and credits don't match exactly (with no override flag, by design), and SHA-256 hash-chaining so any alteration to a committed block breaks the chain and is detected. Cryptography is standard SHA-256 via the browser's own WebCrypto implementation, which is the correct choice; we don't roll our own. The number base is a correctness property, not an access control, and we don't claim otherwise.
Every claim above can be checked directly, which is the part most worth your attention. The Rūnstæf numerals page → runs its conversion functions against the source specification's own worked examples plus a 20,000-case round-trip sweep, live in your browser, and disables itself if any check fails. The double-entry ledger → is a port of a tested reference implementation, cross-checked across 242 cases before deployment; you can post transactions and watch the trial balance reconcile, or deliberately attempt an unbalanced posting and watch it be refused. And on every ledger page on this site, each committed block is converted to base-33 and back the instant it's created, as a continuous live integrity check — visible in the status line beneath the chain indicator, with all displayed figures remaining ordinary decimal.
For technical reviewers specifically, there is a dedicated verification page → that runs the checks on demand at any trial count, exposes the conversion functions on a documented console handle on every ledger page, and — most usefully — lets you deliberately corrupt the conversion table and confirm the check actually fails when it should. A check that only ever reports success proves nothing; that page is built so you can prove this one isn't that.
Sequenced deliberately, each stage a precondition for the next.
Legal entity and commercial licence under DIFC law.
A supervised sandbox to pilot the Echelon components under reduced base-capital requirements.
Fund management authorisation to manage capital and hold client money, with the capital and governance requirements that come with it.
Assessed at scale, once volume and operational maturity justify it — the authorisation that would let Echelon settlement operate for real.
Structured, not improvised: regulated capital management kept deliberately separate from technology operations, which is what any institutional legal team and regulator will expect to see.
Capital is intended to be raised and stewarded through a fund vehicle operating under full DFSA authorisation once that authorisation is in place, deploying into the entity that builds and operates the system. The working structure under discussion is a £25M facility: £15M released on close, with the remaining £10M milestone-gated against stress-test completion and DFSA authorisation progress.
Use of funds: the Echelon Chain build with Anderson Labs (Poland), integrating EBANQ's banking-services layer (Netherlands) as the front office running on top of it, progressing the DIFC Innovation Licence through to DFSA authorisation, and building out the core team.
The operational base moves from the UK to Italy, within the £2M founder-establishment line already in the facility above. The route in is the acquisition of an existing Italian business, which satisfies Italy's investor-visa route through business investment and gives the founder Italian residency; the site's power and space also suit the on-site development and test lab, and it houses his family during the build. Both purposes — residency and lab capacity — are disclosed here deliberately, on the same footing as the other items in Meridian's fit-and-proper record.
Italy also puts the team within practical reach of both build partners by road — through Switzerland to Poland in a single day with an early start, a route that isn't realistic from the UK.