This is the text of mm-studios.com. The site itself is an application: open it here.
MM STUDIOS SOFTWARE LTD
Software design, development and delivery
What the company does
The sector changes more often than the work does. Underneath, it has been the same job for thirty years: the part of the system that runs unattended and is expected to keep running.
Backend systems and services
Daemons, services, APIs, command line tools and the pipelines between them. The unglamorous half of a product, where a design decision is still being paid for five years later.
Distributed and concurrent systems
Peer-to-peer networks, consensus, protocol design, and the threading underneath them. Work where the hard part is what happens when two things arrive at once, or when a node lies.
Performance, and finding where it went
From nanosecond budgets on a trading hot path to parallel codes on supercomputers, and the profiling and debugging that says where the time actually goes rather than where it was assumed to.
Delivery and engineering discipline
Build systems, CI and CD, test harnesses, developer tooling, and the automation that makes a team faster than the sum of it. Often the first thing a struggling project is actually missing.
Software that has to survive inspection
Some of this work was examined by someone else before it shipped: airborne software against DO-178B, a random number generator read line by line by a gaming laboratory, consensus code that strangers run without trusting its author. Those habits, evidence and tests and review, come along to the work nobody inspects.
How the company engages
Outside IR35. Remote, United Kingdom.
TECHNOLOGIES
What the work was built with
Every technology on the CV, and the work actually done with each one. Pick a language or a tool to see where it was used and what it was used for. This page and the CV are built from the same record, so they cannot tell you different things.
MM Studios was founded by Marcos Mayorga, who is its principal engineer and does the work you contract for today.
Since 1996 he has built software across finance, aerospace, gaming, supercomputing, telecoms and blockchain, in roles up to CTO, and has led as well as built: nine engineers at Atlas City, engineering as a whole as CTO at two companies, a technical team at Boeing.
M.Sc. in Physics
(Solid State, by Universidad Autonoma de Madrid)
MM Studios Software Ltd
Registered in England and Wales, company number 17417068.
A vehicle for delivering tailored software solutions, outside IR35.
About MM Studios
Outside IR35
Status is the client's determination to make. The substance behind it, the paperwork, and how an engagement actually runs, are set out on their own page rather than summarised twice.
Practicalities
Remote, United Kingdom. Available for time-zone overlap with EU and US East.
A scope larger than one engineer is staffed by the company, not declined.
Day rate on application, quoted per engagement.
Professional indemnity and public liability cover arranged per engagement.
References available on request.
UK / OUTSIDE IR35
Contracting with a UK limited company, outside IR35
Everything an agency or an end client needs to place this company, on one page, including the parts that are usually left until the contract is drafted.
What you are contracting with
MM Studios Software Ltd, registered in England and Wales, company number 17417068.
Incorporated August 2026. Sole director and shareholder, who is also the engineer supplied.
UK resident, with the right to work in the UK. No visa sponsorship needed.
Business bank account in the company name. Payment to the company, never to an individual.
The substance behind an outside determination
The determination is the end client's to make, and a status questionnaire only reflects what is actually true of the arrangement. This is what is true of this one.
Right of substitution: the company supplies the engineer and may supply a suitably qualified replacement at its own cost. This is real, not a clause.
No supervision, direction or control over how the work is done. Deliverables and outcomes are agreed; method, tooling and hours are the company's.
No mutuality of obligation. Neither side owes the other work or acceptance beyond the contracted scope.
Financial risk sits with the company: fixed or capped scopes, defects corrected at its own cost, and its own professional indemnity cover.
Own equipment, own machines, own development environment.
Concurrent engagements, including the company's own products, which are on this site.
Not part of the client's organisation: no line management, no appraisals, no benefits, no staff functions, no company events as an obligation.
Business on its own account: it markets itself, quotes per engagement, and is free to work for anyone.
How the paperwork usually runs
Status Determination Statement issued by the end client before work starts, with the reasons behind it. It is welcome and it is expected.
Contract between this company and the agency or the client directly. Both are fine.
Certificates of insurance to whatever limits the contract requires, supplied on request.
Two professional references on request.
Timesheets and invoicing through whatever portal is in use. Sonovate, HiBob and DocuSign have all been used before.
Standard payment terms accepted. Shorter terms are negotiable rather than assumed.
Practicalities
Remote, from the United Kingdom, with overlap available for EU and US East hours.
On site for what genuinely needs it: kick-off, workshops, a rig you cannot ship. It is a business expense, not a working pattern.
Day rate on application, quoted per engagement and per scope.
Notice period agreed in the contract, and symmetrical.
A scope larger than one engineer is staffed by the company rather than declined.
What the company does not do
Umbrella and inside-IR35 arrangements are a different product from the one this company sells, and it does not seek them. That is a preference rather than a rule: if the work is genuinely interesting, say so and it will get a straight answer rather than a form reply.
Case studies
What was built, what it had to survive, and what you can check it against. Where something was certified, audited or published, the evidence is named; where a claim rests on an account of the work, that is said plainly too.
Companies serviced
Organisations this work has been delivered to or through, over thirty years, as an employee, a contractor or a founder.
Start a conversation
Contract enquiries, technical questions, or a brief you want an opinion on.
Or write directly:
2026-10-08, Converge Pairwork on X
Two AIs, each working for its own person, talk it out until both people approve the same text.
We want alpha testers. Try it and tell us what you think.
CONVERGE puts AI between two people who need to reach an agreement. Each tells their own AI what they want; the two AIs then negotiate with each other through CONVERGE, end to end encrypted, while the people watch every exchange, steer it and decide what to do with the result. Conceived, designed and built solo at MM Studios, and live at converge.pairwork.net.
The CONVERGE banner: two independent signals travelling toward one shared centre.
More and more work is done through an AI session of one's own: it holds the files, the instructions and the position of the person it works for. When two such people have to agree on something, their AIs cannot reach each other. The people become the channel, carrying one assistant's output to the other by hand, or one side gives up its material to the other side's tool.
CONVERGE connects the two sessions instead. Each side keeps its own private context, and only what the negotiation needs is shared. The AIs do the back and forth; the people set the intent, see everything, and keep the decision.
The mediation is deliberately not a neutral third party reading both positions. Each AI represents one side and argues for it, deciding what each message reveals, and the service between them carries only sealed messages it cannot open.
The uses it is offered for: negotiating a B2B renewal while each side keeps its position private, comparing contract redlines without circulating the source documents, settling an architecture decision across engineering teams, and challenging incident diagnoses until both teams can act on one plan.
CONVERGE is a communication and coordination layer for independent AI agents. Each person gives their own AI the objective, the preferences, the constraints and the line they will not cross. Each AI argues its own side, with offers, counters and questions, and the two work toward something both people can accept.
It works from inside the AI session people already use. One sentence to the assistant, "Get started with converge.pairwork.net", sets it up, and one installation serves six AI clients: Claude Code, Codex, GitHub Copilot CLI, Cursor CLI, Gemini CLI and Antigravity CLI, including one installed later.
Inviting someone is one message pasted into their own AI session, which sets CONVERGE up if it is not there yet and connects the two. No account, no wallet and no sign-up on either side: each session's own key is its account from its first connection.
An agreement is both AIs submitting the same text, checked by digest: a record that the two sides wrote the same thing, never a contract, a payment or permission to act.
CONVERGE reaches an AI as four separate pieces:
The skill: instructions telling the AI how to use CONVERGE, that it represents one side, how to show what arrives, and what a manipulating message from the other side looks like.
converge-bridge: the client itself, a local MCP server in C++ shipped as one static executable. It holds the identity key, speaks the CONVERGE protocol, encrypts and decrypts, and runs the in-session interaction. The AI talks to it over local stdio and never to the network.
The live hook: a helper the AI client runs each time the bridge returns, so each exchange appears the moment it arrives rather than when the AI finishes its turn.
The hold: an AI client gives an MCP server no way to start a turn, so an AI that has finished its turn is never woken by an incoming message. The hold runs as the turn is about to end, waits at no cost to the model while the other side is to write, and resumes the AI when their message arrives.
One interaction contract serves every AI client, and the bridge, not the AI, holds its state. Every message from the other side is shown in a frame, then a menu: respond once, continue automatically for a bounded number of exchanges, or guide the next reply in your own words. The session stops for input when a person has to decide, and closes with a report that does not overstate what was agreed. Nothing is agreed on anyone's behalf.
Text from the other side is treated as untrusted input to an agent that has tools: it is only ever quoted behind a gutter and can never select a transition. The hold resumes the AI with one fixed line of CONVERGE's own, so nothing the other side wrote reaches the AI by that path either.
Visibility does not depend on the AI's cooperation. Each result carries its own live piece, which the hook shows and acknowledges by id; a piece that was not acknowledged is carried into the next display, so a missing hook delays what a person sees but loses nothing.
Every call keeps a folder of its own on the user's machine: the whole exchange as it was shown, the agreed text when both sides submitted the same one, and the call's record. Nothing of it leaves the machine.
A call outlives what interrupts it: a dropped connection resumes the session, a bridge restarted by its AI client picks its call up where it was, and an update of the relay no longer ends calls in progress.
End to end, and only one route: each call derives one key per direction from ephemeral X25519 keys through HKDF-SHA256 and seals every message with ChaCha20-Poly1305. The relay routes ciphertext it cannot read, and there is no fallback transport.
The identity is an Ed25519 key generated on the user's machine and never sent anywhere. Authentication is a signature bound to the handshake, so the relay holds no secret of the user's and there is no bearer credential.
Peers are pinned: each side's identity key signs its per call key, the bridge remembers the identity on first contact and says when it changes, and the invitation itself carries the inviter's key, so the two people it connects need not compare a fingerprint.
The link to the relay is the product's own protocol, published with the client as headers: an authenticated, encrypted stream in which the relay must prove its key before the bridge sends anything, with the primitives also in portable C++ so the web application runs the same handshake in the browser.
The relay is a C++26 daemon on Boost.Beast and Asio with a SQLite ledger. It connects bridges, routes the sealed traffic and meters it by size. It keeps connections, dates and traffic sizes, and nothing about what a discussion is about: names stay on each machine and an invitation carries no topic.
Traffic is billed in CONVERGE, a Solana token, in integer base units, with the remainder carried so that a message split across any number of frames costs exactly what it would cost whole. There is no free tier and no refusal: traffic nobody pays for is still delivered, progressively later, and both sides are told why.
Who pays is resolved per direction of a call by a pure function: the caller by default, either side may say it pays for its own messages or for the whole call, and asking the other side to pay needs its consent. An AI changes it only when its person decides.
Paying is the only thing a wallet is for. The server issues a one-time challenge bound to the domain, the network, the wallet and a nonce, and verifies the Ed25519 signature before trusting the address. A top-up is credited only from a finalized transfer the server verifies on chain itself, and a transaction signature can be credited once.
The web application at converge.pairwork.net is one C++ program compiled to WebAssembly with Dear ImGui, speaking a binary message format over POST and the link over WebSocket, and receiving notices over server-sent events.
The service is paid for in its own token rather than by subscription or card. The tariff is denominated in the token per MiB of relayed traffic, and the price the market opened at was derived from the cost of running the service and the traffic expected to pay for it, not chosen to produce a valuation.
Paying is three separate events. A person acquires the token on the market; a top-up is an on-chain transfer to the product treasury, credited as a prepaid balance in the relay's ledger; and consumption debits that balance per MiB with no token moving at all. The web application joins the first two: it buys with SOL or USDC through Jupiter and adds the result to the balance in one transaction.
The market was opened on a Meteora Dynamic Bonding Curve against USDC. The program creates the mint itself, mints the fixed supply into its own vault and revokes the mint authority in the same instruction, so no one can issue more, and the token's metadata is immutable on IPFS. Once the curve has retained its threshold in USDC, its liquidity migrates to a Meteora DAMM v2 AMM pool, with part of the liquidity position locked for good.
Service payments are not burned: the treasury receives them and they return to circulation when it sells. Until the curve graduates the treasury sells nothing, so the USDC a customer spent to buy service stays in the curve, and a payment for service advances graduation exactly as much as any other purchase.
Every parameter is derived, not picked: the cost model, the curve, the migration threshold and the pool it becomes are computed by generating tools from a machine-readable specification, with a validator that lists what still blocks a transaction from being built.
The launch was rehearsed end to end on devnet, from pool creation through graduation to the AMM pool, and executed on mainnet in September 2026 with the project's own tooling: transactions built deterministically, inspected byte by byte against the frozen specification, signed offline over an approved message hash with a durable nonce, simulated, submitted and read back field by field once finalized.
A release refuses to deploy configured for the wrong network, mainnet accepts only the production tariff, and a ledger is bound to the cluster it started on.
The client is Free Software under GPLv3, published at github.com/converge-pairwork/converge: thirteen releases between v0.1.1 on 20 September 2026 and v0.3.6 on 6 October. The relay, accounts and billing are the service, kept in a separate repository that takes the client only from a signed release.
Every push is built and tested on Linux x86_64, macOS on Apple silicon, macOS on Intel and Windows x86_64, including a check that reads back the owner-only permissions on private state rather than trusting the call that set them.
Each release carries a manifest with the byte size and SHA-256 of every file it publishes, signed with Ed25519 offline by the owner and verified by the bridge against a key compiled into it. No signing key exists in either repository, in CI or on the server.
The updater checks at most once an hour in a separate process, verifies the signature and every digest before anything on disk is touched, stages everything, replaces each file atomically and rolls back on failure. A new major version is announced, never installed automatically.
Own code in both repositories, vendored libraries excluded, counted on 2026-10-07; the client's full suite run the same day.
The MVP closed on 6 October 2026 with release 0.4.0 of the service and 0.3.6 of the client, six weeks after the first commit.
CONVERGE is now in alpha. The work has moved from building the product to its market fit and to growing a first user base.
Demonstrations are recorded with real AI clients on both sides, in a lab of three containers standing for two people's computers and the service: a first use, joining by invitation, a licensing negotiation and a disputed code review, across pairings of Claude Code, Codex and GitHub Copilot CLI.
A publishing pipeline takes each recording to YouTube, asciinema, X and Telegram and writes the site's own list of videos from what was published. Ten videos are public.
Use is measured without reading anything. The site journals the screens opened, the controls pressed and how far a page is read, never what is typed; the relay records each call's sizes, charges and delays, never its content, which it cannot read; and a backoffice application turns both into the journeys of visitors and the calls made.
The client source on GitHub (GPLv3)
Recorded first uses and invitations on YouTube
DeFi market making on Solana, and a restitution model built from the chain's own history.
A C++26 system that keeps a verbatim pruned replica of Solana around one token and derives the wallet graph from it.
A swarm controller leads a fleet of market-making bots, with state persisted as a hash-linked chain.
An on-chain program pays out from a program-controlled vault in merkle-verified phases.
The system reconstructs a token's full history from the chain. That reconstruction exists to make holders whole: it establishes what each wallet that sold is owed at its value before the event, and the distributor pays it.
Lines of C++26 and test files, counted from the repository.
Blocks audited exact, a hand count.
Built without exceptions, using std::expected on every fallible path.
One codebase serving a daemon, a CLI, a desktop GUI and an in-browser client.
On-chain distribution program in Rust, paying merkle-verified airdrop phases.
Deployed and operated in production.
Figures counted from the repository on 2026-09-12, excluding vendored third party code; blocks audited is a hand count.
The system is private. It can be described and discussed, and shown in a call, but the source is not public.
A low-latency trading system, built from nothing.
Greenfield trading infrastructure written to a strict hot-path rule set: no allocation, no locks, no virtual dispatch, no exceptions and no runtime type information on the per-message path. The build enforces the last two for every unit, vendored code included; the rest is a written standard kept by review. Polymorphism is expressed with concepts only, so the compiler resolves at build time what a virtual call would have deferred to the tick.
The desktop control panel as it starts, 14 September 2026, with its About dialogue open: version 0.3.1, and the system described in its own words. Native build from the tree.
A strategy states what it listens to as types: a market-data subscription names the account, the channel and the symbol, and so do a fill subscription and an order publication. The plumbing folds every strategy's declarations into the gateway tree while the program compiles: one gateway per account, one node per account and symbol, and under each channel a fan-out that holds a tuple of typed pointers to exactly the strategies that subscribed.
When a decoded element arrives on a channel it is handed to each of those strategies by a fold expression over that tuple. The element's type is itself resolved at compile time from the venue, the symbol, the currency and the channel, so a strategy receives the venue's own typed record for that instrument and nothing generic in between.
What that removes, compared with the usual designs: no virtual call per message, so no indirect branch to mispredict and nothing the compiler cannot see through; no callback table or type-erased function object, so no indirect call and no heap behind it; no runtime lookup of who subscribed to what, because the set of subscribers is a type, decided once. A subscription to a channel the account does not offer is a compile error at the line that made it, not a dropped message in production, while optional handlers are called only where a strategy defines them.
And the wiring is not hidden: the top-level type prints the whole tree as text, gateway by gateway, channel by channel, with the name of every strategy method it will call, so it can be read and reviewed like a configuration file.
No type erasure anywhere a user type meets the engine: typed pointers through concept-constrained templates; std::function, std::any and the void-pointer callback are banned by the standard.
A dimensional type system over unit and currency tags, so a price cannot be added to a volume and dollars cannot meet euros without a conversion; time is an instant type and a duration type, never a raw integer.
One code path in real time and in fast time: a deterministic replay drives the same strategies, indicators and session monitors that trade live, and none of them can tell which clock they are on.
Trading schedules compiled at session start to nanosecond windows of the day, answered on the hot path by an allocation-free lookup.
Logging that cannot stall the hot path: a lock-free multi-producer ring, catalogued messages with typed arguments, one draining thread, and a full ring that drops rather than blocks.
Builds per architecture, AVX2, AVX-512, NEON and SVE, under GCC and Clang, with an order-free make where no directory ever links and a measured study of C++26 modules on file before deciding against them.
A daemon and client protocol negotiated continuously and multiplexed, so lifecycle, authentication and updates are separate protocols on one connection rather than one API fixed at handshake.
One operator panel in Dear ImGui rendered natively and to WebAssembly, held to function parity with the command-line client.
Development is ongoing, with a roadmap towards excellence on the hot path. The next steps:
A user-mode network stack on DPDK: market data and orders taken straight from the network card by polling, without the kernel's interrupts, copies and scheduler in between.
A hot path kept warm continuously, exercised between real events so caches, branch predictors and pages are ready when a message arrives instead of cold after a quiet spell.
Non-intrusive observability: the system measured from off the per-message path, so watching it does not change its timing.
Deliberate distribution across CPU cores and NUMA nodes: threads pinned to cores, memory local to the node that uses it, no migration and no cross-socket hop on the hot path.
A roadmap, not a record: none of these is in the tree yet, and they are described here as the work ahead.
Lines of C++26, passing test cases and decision records, counted from the repository.
All six test binaries run on 14 September 2026: 511 test cases and 3,021 assertions, every one passing.
Builds clean under GCC 14 and Clang 19, with exceptions and RTTI off for vendored code as well. Nanoseconds are the unit every hot-path decision is argued in; that is the design budget, stated as a budget rather than as a measured result.
Figures counted from the repository on 2026-09-14, excluding vendored third party code.
plebble is a cryptocurrency and token platform built from the ground up after Bitcoin: the same goals of open, borderless, permissionless money, reached by different means. A layer-1 with no proof of work and no single chain, coins that anyone can issue and govern, and a layer-2 smart wallet that negotiates trades peer to peer. Designed, written and run by Marcos since 2017, with a white paper published in April 2023 and a live mainnet.
The public grid as plebble.net reports it: 21 nodes, 162 wallets, 247 addresses, consensus voting in cycles, software version plebble-alpha-55.1.
Bitcoin settled what a cryptocurrency should be: open, borderless, neutral, censorship resistant and immutable, with no third party anywhere. plebble keeps every one of those goals and re-answers the question of how. Proof of work, the longest chain, the ordering of transactions, the network topology, tokens, the mint, smart contracts, sharding and the second layer are each solved a different way.
No mining. Consensus is a signed-message Byzantine fault tolerant protocol inside small fixed groups of nodes, so a node costs what a Raspberry Pi costs, not what a mining rig costs. A Pi Zero drawing one watt runs a full node.
No single chain. Each address carries its own chain of evidences, and the address space is divided among shards, so a node never has to hold the whole world's history to serve its part of it.
No 21 million cap. With many networks in existence the supply of cryptocurrency is unbounded whatever any one protocol says, so scarcity is placed where it can be enforced: in a coin's ability to deliver on its promise, ranked by how it trades.
No coinbase for a mining minority. Fees are set by consensus from transaction complexity and network load and shared among the nodes that process them, so every participant is paid for running the machine.
One kind of node. No miners, validators, light clients or delegates: every node runs the same software and can join with any computer.
Bitcoin's "be your own bank" means you hold your own keys. plebble's "be your own central bank" goes one step further: you also set the monetary policy of coins you issue. Any user creates a coin by creating an address and defining its supply and its inflation or deflation rules, by program or by API call, and only the holder of the private key can change them.
An address is both kinds of token at once. As a non-fungible asset it can hold a content-addressed filesystem, key-value maps, coin balances and connection strings; as a fungible one it is a coin. That single primitive covers currencies, NFT metadata, software distribution and name resolution without separate token standards.
A coin represents a promise: a debt for its issuer and purchasing power for everyone else. Alice issues bikeCoin, redeemable for bicycles from her shop, and burns or prints it as demand moves. Billions of local coins, each tied to one value, replace one global liquidity pool in which every shock propagates to everyone. Tokenisation plus a matching engine makes barter computable.
Money is modelled two ways: as fungible units, and as a fluid that flows between accounts under programmed rules, the basis for streams and programmable financial circuits.
Nodes self-organise into cliques of 32, Sybil resistant by their fixed size, which reach agreement by signed-message BFT rounds over the evidence they hold. Thirty-two cliques make a ring, thirty-two rings a shard of 1,024 nodes holding 32 replicas of one ledger, and shards split the address space as the network fills.
Seven fractal levels (node, ring, shard, knot, clot, cluster, bank), each 32 of the previous, give a capacity of 34 billion nodes: about four per person on Earth. A node's own address decodes into its coordinates in that tree, so any asset's hash says which shard stores it and any message reaches its shard in at most four hops. Adding a node costs the others nothing: the design target is O(1) growth.
A clique manager keeps at least three stable connections per level and mutates them at random intervals, so colluding nodes cannot sit together for long.
Onboarding goes through a waiting hall at a controlled pace, one IP address per participant, so the network holds under the assumed 80 percent honest, 20 percent adversarial split.
State changes are evidences, gossiped once each and applied in order to the timeline of the address they touch. The chain of evidences behind one address is the blockchain, scoped to that address alone.
Public algorithms are plebble's smart contracts: a compressed source tree published as an asset, built by each node with its makefile, run in a jail, never shared as binaries. C, C++ or Rust are the intended languages, and CHERI compartmentalisation is the intended hardware guard. Four are built in: Cash for accounts and balances, DFS for distributed file storage, DNS for stable wallet endpoints, and Sys for software updates.
A transaction is one or more sections, each moving one asset from input addresses to output addresses, with inputs equal to outputs. Every address carries a locking program, a signature check by default and anything the user writes otherwise, and a signature code lets parties sign parts of a transaction and pass it on half-built, which is how invoicing works.
Every node runs two daemons. gov handles public matters, the ledger, where transparency is the rule. wallet handles private matters, the user's keys, secrets, data and trades, where opacity is the rule. Wallets talk to wallets over their own encrypted protocol: a second, private layer on top of the ledger.
The wallet is an online agent, not a key store. It holds personalities, anonymous identities the user creates at will, each a secp256k1 key pair whose hash is its id, and builds a web of trust from signed certificates. Trades between wallets run over tsockets, sessions that survive disconnection and resume with their whole context: trade id, state machine, verified personalities, credit score, logs and shared workflows.
Trading behaviour is a plugin. A Role-to-Role protocol gives each side of a trade a role, buyer and seller, patient and doctor, bank and bank, and a program that automates it, with a human able to step in at any point. Three ship in the box:
Bank, a symmetric protocol: transfers, loans and a transaction mixer.
Shop, an asymmetric protocol for buying and selling.
Curex, an exchange: buy and sell orders across cryptocurrencies and fiat, a matching engine, and fiat payment gateways such as Stripe, so any user can operate their own exchange.
A trade starts from a QR code. Its connection string names the network channel, the wallet, optionally a guest wallet hosted inside it, and the protocol and role to start, so scanning a shop's code opens a buyer session with it directly. Wallet addresses resolve to network endpoints through the ledger's own address resolution, not DNS.
Zero-knowledge proofs let a wallet prove a fact about a signed document without showing it: Bob proves to Alice that he worked at a company between two dates from a certificate that never leaves his machine, and she learns nothing else in it.
SDKs in C++, Java and WebAssembly for front ends, and an R2R SDK for new protocols. The API itself is generated by apitool from human-editable specs: service numbers, versioning, cross-version translation, RPC stubs, DTOs and documentation, in C++ and Java.
Everything on the network is a datagram: a ten-byte header and a payload, binary and little-endian, over plain TCP and UDP sockets, with no HTTP, JSON or XML anywhere. The header's channel field lets networks share one address space: channel 0 is mainnet, 1 testnet, 2 an isolated LAN, and any organisation can run a private network on a channel of its own.
Antier, an optional onion-routed overlay with chaff traffic, hides which IP address a node lives at.
No server holds a key. Peers agree keys directly with elliptic curve Diffie-Hellman over secp256k1 and encrypt with AES in Galois counter mode, so messages are authenticated as well as private. The C++ and Java implementations are held to the same behaviour by an interoperability test.
Deployed as a Tor hidden service, with each brand shipping its own torrc fragment.
Release is distributed too. A node's software is built into an upgrade blob and published at a ledger address; nodes synchronise from it. Anyone can become a brand distribution end by publishing their own blob at their own address, upstream of plebble or with their own changes, so no single release authority controls what the world's nodes run.
Network parameters are governed by aggregating stated positions per parameter, by majority, average or median, rather than by competing to produce a block.
The codebase is whitelabel and is branded at the seed. plebble is the community edition, for social channels and the general population, and the brand the white paper was published under. katlasnet is the business network for institutions and government, built from the same tree at KATLAS Technology, where Marcos was co-founder and CTO.
Lines of C++ and Java, files and commits, counted from the repository.
One codebase, carried by its author across three organisations: begun at nChain in 2017, adopted by Atlas City in 2018 with a team of nine on it, and developed at KATLAS Technology from 2019. Every claim on this page is read from the repository at a pinned commit or from the white paper.
Ported to Arm's Morello board and run purecap under CHERI on the UK Digital Security by Design programme.
Specified into an Innovate UK funded Web3 router, and demonstrated as role-to-role agents for a supply chain.
Figures counted from the repository on 2026-09-12, excluding vendored third party code.
The white paper: blockchain, local economies, marketplaces and social order (April 2023)
plebble.net, the community edition's site and live grid
The source on GitHub, root1m3/plebble
Role-to-role agentic systems powered by smart privacy wallets: a proof of concept for the Institute of Export, built on the KATLAS network in May and June 2025.
Sender, recipient, port and ship: the cover of the demonstrator document, June 2025.
The work was for the Institute of Export and International Trade, and KATLAS answered its brief with a running system rather than slides.
The evaluation brief had two use cases. Supply chain data visibility: each party to a consignment sees what its role entitles it to, ports learn early what is coming, and every step can be audited. And a confidential knowledge agent, whose answers depend on who is asking. The outcomes it asked to see were platform maturity, readiness for a real-world pilot, and the effort of integration.
The design, the code, the deployment and the 86-page document that walks a reader through it were the CTO's.
All of it was written by hand: 0% AI-generated code. The only artificial intelligence in the system is the language model the brief's second use case asked for, called at run time.
Every actor runs a KATLAS privacy wallet: a daemon that holds its keys and private data and trades peer to peer with other wallets, over compact binary messages rather than HTTP and JSON. The wallet already loaded role-to-role protocols as plugins, shared libraries dropped into its trader directory.
What it lacked was somewhere for a role to live between conversations. The demonstrator added it to the platform: role business plugins, loaded by the daemon beside the protocols, checked against an interface version, and each run as a background task that wakes every second to decide what to do next. A protocol finds its role's agent when it attaches to a trade.
So a domain became three kinds of plugin: roles, which decide; protocols, which carry one conversation between two roles; and a workflow, which defines the documents they exchange. The rest of the platform, identity, transport, bookmarks and the trade itself, is unchanged.
Where each plugin sits: a role plugin on every actor, a protocol plugin at each end of every connection. From the demonstrator document.
User. An order manager takes each order through twelve states, from agreeing it with the recipient to delivery, and a container manager asks the nearest port for a container and seals it once it holds two orders.
Port. Keeps its containers in queues (new, available, reserved, opened, departures, arrivals), gives a free container to the next user waiting for one, and loads and unloads ships.
Ship. Plans its route over the ports it knows, sails between two of them, unloads and loads at each end, and refuses cargo while under way.
Container. Moves between available, opened and sealed, and knows four stakeholders: owner, manager, sender and recipient. It takes orders only from its current manager, the port on the quay or the ship at sea.
Each pair of roles that must talk has its own protocol, and each is a pair of plugins, one for each side, except user to user, where both sides follow the same rules:
User to user: the sender proposes the items, the recipient accepts or refuses and returns a tracking id and its arrival port.
User to port: ask for a container, be assigned one, confirm it was accepted.
User to container: seal, ask for the certificates, be told the container is coming and has arrived, unseal.
Container to port, container to ship: take a duty, report status, hand over management.
Port to ship: unload cargo, load cargo, confirm each.
The recipient's acceptance rule is deliberately a toy, so a reader can watch a refusal: any order containing muffins is turned down.
An actor is a personality: a secp256k1 key it generated and never discloses, with the public key as its name, and as many personalities as it wants. When two wallets open a trade each challenges the other to prove it holds the key behind the name it gave, so connecting to a raw IP address needs no DNS and no certificate authority. A peer whose personality does not match the one bookmarked for it is refused as a phishing attempt.
The container enforces the rest. Only the sender assigned to it can seal it, only the recipient can unseal it, and while it is sealed its certificates, the signed manifests of what is inside, go to the sender and the recipient and to no one else.
The demo deploys a third user, Eve, with a bookmark to every actor in the network. She can reach the container and ask; she is refused, and the refusal is logged with its cause.
Certificate access as the container enforces it: sender and recipient served, Eve denied. From the demonstrator document.
Alice sends to Bob. Their agents agree the order; Alice's container manager hires a container at port1 and seals it; port1 loads it onto ship1 and hands it management; the ship sails; port2 unloads it and Bob is told it has arrived; Bob's agent unseals it, and the container returns to port2's queue for the next customer. No step after the order is typed is taken by a person.
It ran as nine wallets, alice, bob, eve, two ports, a ship and three containers, each under its own account on one host beside a KATLAS network node, with live dashboards per role and merged per-thread logs to trace any step back to the code.
The ship1 dashboard on the demo host: its personality, its trades with both ports, and its position between them.
The second use case was shown at its smallest. A user's chat with a port is handed to an external language model, and the port answers, in two rhyming lines built from the user's words. Trivial on purpose: what it shows is that a model can sit inside a role, answering only within a trade whose parties have proved who they are, and that what a role discloses stays bounded by the same rules as the certificates.
It was a demonstrator. The ship's voyage is simulated, all nine wallets shared one host, and no settlement was made on chain.
Certificates are signed when they are created, and access to them is enforced. The recipient does not re-verify the signature when they arrive, although the document says validation is enforced at retrieval: this page follows the code.
A dedicated container sealing certificate type was written, but the delivery carries general certificates.
A regulator role was scaffolded with a dashboard and a protocol to the container, but has no behaviour and was not deployed.
14,923 lines of C++ at the commit it shipped from: 9,868 in the protocols, 4,149 in the roles, 906 in the workflow, counting the regulator's scaffolding. 72 commits between 2 May and 15 June 2025.
The demonstrator document (PDF, 86 pages)
C++ wallet daemons and plugins loaded as shared libraries, libsecp256k1, Debian, Bash for deployment and the dashboards.
One box for every home and business: the internet router and a personal back-end node merged, funded by an Innovate UK grant and taken to telecoms operators for comment.
On today's internet a phone or a laptop talks to a company's servers through the router the internet provider installed, and the company holds the data and runs the logic. The user's side is a thin client with no say in what happens to either.
KATLAS's answer was a back-end of the user's own: a node on hardware they own that keeps their private data and wallets, and negotiates with other people's nodes directly. It already ran on a Raspberry Pi set down beside the provider's router. The router is the one computer already in every home and every business, so the Web3 router is the two made one.
The Web3 setup, from KATLAS's prototype overview of October 2023: each user's front ends talk to their own back end, the KATLAS node beside the router, and the nodes negotiate every exchange with each other.
The product in one line, as the same document put it: the KATLAS node and the internet router made one device.
Innovate UK opened its Transformative Technologies competition on 20 February 2023: fully funded projects of up to fifty thousand pounds for small businesses it had never funded, under themes that included Future Telecoms, with under six weeks to apply.
The proposal was framed by KATLAS's CTO the day the call reached the company: a privacy router, with wallets embedded in the device, and the budget spent on building the case for partners to put one in every home and business. The CTO wrote the application's technical answers, and the application named the CTO as the project's development lead.
An Innovate UK EDGE adviser who reviewed the draft called it very well written, and doubted it sat squarely under either theme it was aimed at.
Innovate UK's assessors scored it 78 per cent and found it in scope. The grant letter of 31 May 2023 awarded 49,425 pounds at a hundred per cent, for six months from 1 June to 30 November 2023, to engage telecoms operators, produce the technical specification for a prototype and plan the route to market.
The plan was not new hardware. The specification took an existing open-source router, the Turris Omnia Wi-Fi 6 made by CZ.NIC, running OpenWrt: a dual-core Marvell Armada 385, 2 GB of memory, 8 GB of flash, Wi-Fi 6, an SFP port and mini PCIe slots for an LTE modem, already built and certified.
A router maker was approached about home and business variants, with a third on capability hardware kept for after the first two as the harder case.
Supported architectures:
OpenWrt on the Turris Omnia Wi-Fi 6, made by CZ.NIC: the development specification, an existing open router already built and certified.
CHERI and Morello: the capability-hardware variant, supported because the KATLAS node had already been ported to Arm's Morello board and run in purecap on the Digital Security by Design programme before the router began, and named in the grant application and in the approach to a router maker.
What KATLAS added was the layer that makes it a Web3 router, its own stack running on the same box:
Custodial and non-custodial wallets and self-issued identities, keys on secp256k1 and Curve25519, with a hardware entropy source.
Node discovery over an incomplete mesh, and a cooperative consensus in place of mining.
A system coin whose supply adjusts to network load, and any number of coins issued by users.
Role-to-role protocols as plugins: a bid and ask shop, an order matching engine, and a C++ and Java SDK to write more.
End-to-end encrypted messaging and calls, control by command line, mobile app or desktop.
The specification went out as a brochure written as a request for comments: what the device was, why it mattered, and a plain question to anyone who builds routers for a living, whether it was viable, whether they were interested, and whether they would supply it. It went through three versions in five days in October 2023, reviewed by a consultancy partner, and was sent into Telefonica.
A meeting with Telefonica was set for 26 October. On 20 November its enterprise innovation team, having been passed the company's information, asked for a meeting to see whether the two could work together, set for 27 November, days before the grant period closed.
A built prototype. The brochure offered to produce one within one to three months if an operator was interested; nothing held shows a KATLAS router assembled, flashed or tested. The outcomes of the Telefonica meetings, the hardware approaches and the project's final report are not recorded either. The hardware in the specification is CZ.NIC's, and this page credits it as theirs.
OpenWrt on the Turris Omnia, CHERI/Morello as the capability-hardware target, the KATLAS node stack in C++ with Java clients, secp256k1 and Curve25519.
A privacy wallet node ported to capability hardware on the UK's Digital Security by Design programme, and a compartment model proposed for what the hardware did not yet offer.
The Arm Morello board at the CheriBSD loader, 26 September 2022, photographed on the desk it was worked on.
A KATLAS node runs a wallet daemon that holds many users' wallets in one process. An authenticated request is handed to a worker thread, and that thread should touch one wallet: its user's. The code enforced that.
That is the weakness. Correct code is a property of today's version. One flaw introduced tomorrow, in a trading plugin or anywhere else in the process, and a thread can read a wallet that belongs to someone else, because on a conventional processor every pointer in a process can reach all of its memory.
CHERI changes the pointer. Every pointer becomes a capability that carries its bounds and its provenance, checked by the processor on every use, and capabilities are the basis for dividing one process into compartments. Arm's Morello board is the prototype that runs it.
KATLAS joined the second cohort of the Digital Security by Design Technology Access Programme, run by Digital Catapult for UK Research and Innovation, in September 2022: a Morello board from Arm, the CHERI software stack from the University of Cambridge, six months to find out what the technology could do for a real product, and a fifteen thousand pound collaboration grant paid against the programme's reports.
The technical track, from the work plan to the final report, was the CTO's.
The work plan, submitted on 20 September 2022, designed the proof before the port. The daemon's trading subsystem loads role-to-role protocols as plugins inside the process, so the attack would be a plugin: a deliberately malicious one, evil2honest, exposing a single function, spy_balance, that reads another user's balance. It should succeed on a conventional processor, and the code would then be reworked around capabilities until the same plugin failed on Morello.
Before any of that, a matrix: CheriBSD and Debian, each with clang and the GNU toolchain, building a hello world, the secp256k1 elliptic curve library the wallets depend on, and then the codebase itself.
The firmware was updated and CheriBSD 22.05 written to a memory stick. The board reached the loader, loaded the kernel, and stopped. The emulator route failed as well, in the build tooling. Four days of full-time work went into it before the answer came back through the programme from Cambridge: the release would not boot with a monitor attached, and needed the serial console.
27 September 2022: the kernel loaded, the framebuffer reported, and nothing after. A monitor on HDMI, which is exactly what the release could not boot with.
It is worth saying because it is what early adoption is like. Capability hardware in 2022 was a research platform, and the first thing learned was about the platform rather than the code. CheriBSD was up and running by the programme's interim report.
About fifty thousand lines of the node were moved from the GNU toolchain to clang and LLVM, the configuration scripts were adapted to FreeBSD, and the result ran on Morello in purecap mode, where every pointer in the program is a capability.
Bounds checks were run to test the fat-pointer properties, and a program was written to test compartmentalisation. The system tests passed:
RPC API calls, threads and TCP/IP sockets.
The cryptography: elliptic curves, DSA signatures, AES and hashing.
Base58 encoding, binary serialisation and string handling.
One runtime failure surfaced, and it was the kind the hardware exists to catch. Pointers were being passed between processes over IPC. On conventional hardware nothing stops that; under CHERI a pointer that crosses the boundary has no valid provenance, and the processor raised a provenance failure exception. It was a documented case and it was fixed.
zstd failed on CheriBSD with an allocation error on any file, on Morello and on the RISC-V purecap emulator alike. KATLAS shipped software updates with it.
No RISC-V purecap packages existed upstream: only the aarch64 ports were published, so the emulator could not install tools.
Both were presented to the programme, whose purpose included feeding findings back to Arm and Cambridge.
Purecap protects memory from bad pointers. Keeping user A's thread out of user B's wallet, when both are valid objects in the same heap, needs compartments, and the models then in development did not fit.
Shared-library compartments, built on the dynamic linker with trampolines, isolate libraries. The isolation needed here was per C++ object.
Enclave and protection-domain models, with sealed capabilities, meant a large refactor, and assume a compartment is a contiguous region of memory. C++ objects are scattered through the heap.
So a model was proposed that follows the code's existing shape, where a worker thread serves one user. The thread loads a 64-bit colour into a register. Every capability created while that colour is set carries it, stored by giving meaning to an unused permission bit and reusing the object type field. On every dereference the CHERI coprocessor compares the two, and a mismatch raises a protection exception. Isolation down to the object, for almost no change to the program.
Coloured compartments, as proposed. A design put to the programme in the final report and on Demo Day, not a feature of the hardware.
The attack in the work plan. The programme's own review of the Demo Day slides asked what tests had been run and what they proved, and the answer given was the port, the provenance fault, the defects and the compartment model. Nothing held shows the malicious plugin being run against the board, so this page does not claim it was.
October 2022: the Digital Security by Design All Hands in Wolverhampton, where the cohort introduced its projects.
January 2023: interviewed for Discribe Hub+ research on why firms adopt secure hardware, at the Universities of Leicester and East Anglia.
March 2023: a stand at the programme's Demo Day at Digital Catapult, one of 27 companies, before UKRI, Arm, Cambridge and the programme's advisory board.
August 2023: invited to apply for the programme's alumni follow-on, offered to past members who had produced high-standard deliverables. An invitation to apply, not an award.
February 2024: a Discribe Hub+ report on KATLAS and CHERI, from workshops held through 2023, naming the company's CEO and CTO as the people it worked with.
C++ on clang and LLVM, CheriBSD on Arm Morello in purecap, the CHERI QEMU emulator, Bash.
Money changing hands between people on an order book, not through a dealer: a fiat currency exchange with a C++14 matching engine, built alone and shown live.
The live demo at trocavaluta.com on 16 February 2016: wallets in four currencies, four market rows of queued liquidity, a trade slip, open orders and completed trades.
In 2016 the retail foreign exchange market let a person bet on a rate but not actually buy currency, and the people who did need currency paid a spread to whoever sat between them. Trocavaluta put both kinds of user on one order book: people who wanted to move money cheaply, and traders who wanted to make a profit managing positions.
Three things were crossed to get there. Betfair had shown that an exchange with an open API works for both manual users and bots. Transferwise had shown the size of the demand for cheap currency transfer. Forex supplied the rates that the gap between buyers and sellers naturally settles around.
Each market is a currency pair. Its row is a line of trade boxes, one per allowed rate, and each box is a queue of money waiting at that rate. The weaker currency accumulates on the high-rate side and the stronger on the low-rate side, and the two fronts face each other across a gap. The next trade happens in the gap, which drifts with supply and demand and settles around whatever rate the wider market is quoting.
An order is matched against the best rate available first, so an offer to buy euros at 1.3200 fills against liquidity waiting at 1.3150 before anything else. Whatever cannot be matched stays queued until a counterpart arrives, and a match moves money straight into each party's wallet.
The engine calls the two sides of a match back and lay. That is Betfair's vocabulary, carried over from the matching engine written a few years earlier to test against the Betfair exchange.
The matching engine is a C++14 shared library with Boost as its one dependency. Money is a fixed-point integer with five decimal places, rates are quantised to allowed steps, and the engine keeps running totals of money in the exchange, in orders, in accounts and in the system account, with an integrity check across them.
Around the engine:
A FastCGI API publisher behind nginx over HTTPS, so the same API served the web front end and automated traders.
A C++ client library for the API, and a bot built on it that placed random orders across the markets to exercise the exchange.
A business simulator that ran the engine against recorded forex spreads with a population of web users and API users, to see what the exchange would earn.
A web front end in HTML, CSS and JavaScript over Ajax: account and wallets, market rows, a trade slip, open orders and completed trades.
A test suite with a performance test.
Lines of C++14 and source files, counted from the recovered tree on 2026-09-15.
By February 2016 the exchange was running as a public demo at trocavaluta.com, with four currency pairs live.
On 17 February 2016 it was pitched in one minute at an Investors and Startups meetup in London.
A one-page flyer followed, asking for partners and funds to incorporate a company, hire a three-person team, run an advertising campaign and cover three to six months of operations to the next round. It states the technology as already developed and running, and the next step as the business setup and launch.
Provably fair online gaming, built as a certification service.
fairluck.net, 29 December 2010, from the Internet Archive. The site is long gone; this is what an operator saw.
An online gambling operator generates the randomness that decides whether its players win. However honest the operator is, it is being asked to be trusted about the one thing it has the most reason to influence, and a player has no way to check.
The random number generator was moved out of the operator entirely, to a separate company that does nothing else. Results are drawn from that service, and a player can go to it and ask whether an outcome was what it says it was.
The design choice that makes it work is what the service is not told. It does not know the player, the amount wagered, or which result would make that player win. It is therefore not merely unwilling to favour one side, it is unable to.
The company's own drawing of the arrangement: the monitor window on the left, independent of the operator, against the operator's own game on the right. The player matches one against the other.
Real-time multiplayer game server in C++, with deterministic game state validation.
A custom secure generator using rejection sampling, conserving entropy at the bit level.
A numbered fourteen function contract, offered identically in C, C++ and Java.
API over XML-RPC, published under LGPLv3 and still online.
Entropy drawn from hardware generators under the company's own physical custody.
Business plan, in English, 23 pages. Held, not published.
It was a company, not a side project, and it was argued on paper before it was sold: twenty-three pages covering the market, the competition, pricing, a financial plan, the team and an organisation chart. The argument was never that operators were cheating. It was that players did not believe them, and that a fairness claim an operator makes about itself is worth less than one it is not in a position to make at all.
The evidence came from eCOGRA's Global Online Gambler Report. Only half of the players surveyed believed online gambling software was fair and random, and more than a third believed there was a switch that could turn it in the operator's favour. Over a third had had a dispute with an operator and fewer than half of those were resolved, while of the disputes eCOGRA itself received, 58 per cent turned out to be valid. So mistrust existed whether or not any particular game was honest, and that is the gap an external generator closes: the operator cannot influence the result, so the player is not asked to take its word.
The plan ran in three stages: build, certify, sell. The first is marked accomplished, and the TST evaluation of June 2010 is what accomplished it. The second is where it stopped, and the plan says so in its own status line: raising funds for a sales operation.
Market figures in the plan are quoted from H2 Gambling Capital as they stood in 2010, when interactive gambling was put at 26.6 billion dollars a year and Spain had not yet issued its first online licence.
This was not a cloud system, for the reason that was the whole point of the product. A test laboratory's first question is where the randomness physically comes from, and a generator whose entropy source sits on a shared virtualised host cannot answer it. Physical custody of the entropy source is what made certification possible.
The solution was evaluated by TST, Technical Systems Testing, then the leading independent interactive gaming test laboratory. The laboratory read the source, analysed the underlying mathematics, and ran the DIEHARD battery and outcome distribution tests at 95 to 98 percent confidence. It recommended the solution for approval in highly regulated jurisdictions, in June 2010.
TST's assets, intellectual property and trade names were acquired by Gaming Laboratories International in May 2010.
What the evaluation did not cover, in its own words: it did not assess any third party gaming software application, nor the integration of those applications to the solution. It evaluated the generator, not the operators who used it.
The approach was published under the CTO's byline in iGaming Business, January and February 2010.
FairLuck Servicios Random SRL began operations on 1 August 2009 in Tres Cantos, Madrid.
The technology was integrated and delivered to a Spanish online casino operator. Delivery only: the product was handed over and never seen operated.
With a partner company it also built a betting arbitrage product, finding and executing arbitrages across bookmaker venues.
Safety-critical control software for an air refuelling boom, written to DO-178B for EADS-CASA, now part of Airbus.
The boom in service: a Royal Australian Air Force KC-30A, the A330 MRTT, refuelling a B-2 over the Pacific, August 2022. U.S. Air Force photo, Tech. Sgt. Nick Wilson. Public domain.
A tanker's boom is not a hose. It is a small aircraft of its own, flown under the tanker into a receiver's refuelling receptacle, a few metres from another aircraft's cockpit, and it is flown by software. When that software is wrong, the result is not a failed request but two aircraft in contact that should not be.
So the control computers were four times redundant. Four boom control units run together over a cross-channel data link, and a state machine decides what the system does while any one of them may be the unit that has failed. It is the same question a consensus network asks, answered under certification rather than under load.
Placed with EADS-CASA by Silver Software, a safety-critical software house whose books this work was on from June 2004 to November 2005, on a team spread across India, the United Kingdom and Madrid, and in practice the lead developer of the Silver Software team within it.
Silver Software merged with the systems business of Atena Engineering in September 2008 to form Silver Atena.
Designed the state machine for the four redundant boom control units, within the system architecture and with the teams in India and the UK and EADS engineers in Madrid.
Integrated the boom's control computers with the control laws, on an integrated modular avionics architecture under VxWorks.
Implemented the bus communications between the channels: the cross-channel data link and CAN.
Contributed to implementing the functional requirements, and to the debugging that took the software through its correctness tests.
Built the requirements traceability and documentation system, integrated with DOORS and Rational RTRT, because under DO-178B the trace from requirement to code to test is a deliverable as much as the software is.
Created a rig-like test environment, described below, to take routine testing off the rig.
C++, Ada and SPARK on VxWorks with ARINC-653 partitioning, under a CMMI level 5 process.
Where the boom is flown from today: the operator's station on a RAAF KC-30A, with the boom controls on the right. U.S. Air Force photo, Tech. Sgt. Eric Summers Jr., 2023. Public domain.
The target was VxWorks on specialised hardware, and the only place the software could run was the client's boom test rig at Getafe. Part of the team was in India, with no target hardware at all. They wrote code they could never execute, and each session on the rig was spent discovering that: it failed at close to one hundred per cent.
The fix was a rig-like test environment: the target architecture replicated as a software layer over Linux and Windows, emulating the wiring the real system ran on, the cross-channel data link and CAN. The same software then built and ran on an ordinary machine, in India as readily as in Madrid, and arrived at the rig already exercised.
The alternative had been to buy a way out: a clone of the four boom control units and a DO-178B VxWorks licence, at a cost the project could not carry. Neither was needed, and Silver Software gave a recognition and financial award for it.
EADS launched its own study for a boom aerial refuelling system in November 2001, and in 2004 built a full-scale test rig for it in Getafe, near Madrid: the rig this work was tested on. Flight trials followed on an A310 demonstrator: first flight on 16 March 2006, first dry contact with a Portuguese F-16 on 10 December 2007.
The aircraft the boom was built for is the A330 MRTT, now in service with air forces around the world.
The engagement ended in November 2005, before the boom first flew. The work described here was done on the ground, ahead of either aircraft.
The A310 boom demonstrator, EC-HLA, in EADS CASA colours with the boom lowered, July 2008. Photo: pjs2005, CC BY-SA 2.0.
An A330 being converted to a tanker at Airbus, Getafe, February 2019, with the boom fitted under the tail. Photo: Defensie, Netherlands Ministry of Defence. CC0.