How it is built, and why it is built that way.

Organisations, members, customers, suppliers, invoices, quotes, products, reporting. Stateless and horizontally scaled. It never does heavy work inline; anything slow is published to a queue and picked up elsewhere.

Watches the public addresses you have connected or asked us to watch. Backfills on connection, then follows continuously, handling reorganisations and keeping its own cursor. Every chain sits behind the same interface, so adding one is an implementation rather than a rewrite.

Builds payment requests, generates the payload behind a code or an NFC tag, and holds the live connection that turns the till green. Latency matters here and nowhere else, so it scales on its own.

Invoices, quotes, statements and year-end packs, rendered to PDF from the same templates the web pages use. Queue-fed, never called from a request path.

Reminders, recurring invoices, reconciliation passes, capital gains recalculation, scheduled reports, retention jobs.

The single point at which we ask anyone for a price, cached for everything else. It exists so a valuation is taken once, consistently, and recorded rather than recalculated later.

Business profiles, the directory and the map. Read-only, cached, and served from a replica so consumer traffic can never contend with a till taking a payment.

Signing up takes an email address and a way to pay for the subscription. No identity documents, no proof of address, no selfie holding a passport. Verifying your company against Companies House is optional and exists only because some businesses want the badge on their public profile. Data not collected cannot be lost, leaked, or asked for.

Customer and supplier identities, contact details, addresses, the labels you give wallet addresses, invoice line descriptions and document text are encrypted at the field level before they are written, under a key belonging to your organisation alone. Anyone reading the raw database sees transactions against addresses, with no way to tell whose they are.

Fields that need looking up carry a keyed hash alongside the ciphertext, so exact-match search still works without the value being readable. The key is per organisation, which means the same email address in two different businesses produces two different hashes. Nothing can be matched across the platform, by us or by anyone else.

Numbers and timestamps are not the sensitive part, and keeping them readable is what lets your VAT return and your capital gains be calculated on the server rather than in your browser. Encrypting them would buy nothing and cost you the reporting that is the reason to use Ceodore at all.

A customer using the Ceodore app can see everything they have bought, everywhere. No merchant can see that. A business sees the customers who bought from it and nothing beyond, and the cross-merchant view is held under the customer's own key. It is the most sensitive dataset in the product and it is treated as such.

No data sold, no data shared with advertisers, no data used to train machine learning models, no advertising trackers in the product or on this website. Everything stays in the United Kingdom, and you can export or delete it yourself without asking anyone.

Your till asks for a payment request. We build one: amount, asset, reference, and your own receiving address. It is written to an NFC tag or rendered as a code, and it expires on a short timer so a tag left on the counter cannot pay for the previous order.

The customer's wallet opens with the amount already filled in. They approve with their own biometric on their own device. The transaction is signed there and broadcast from there. Ceodore constructs; it never signs.

Funds move from the customer's wallet to yours, directly, on a public network. No intermediary account, no pooled balance, nothing of ours in the path. Settlement is final and cannot be reversed by us or by anyone.

The indexer sees it and the payments service tells the till, which is why the screen turns green in about a second. Both are watching the chain, not each other.

The transaction is matched to the invoice or till sale, valued in sterling at that timestamp, classified against a nominal code, added to your Section 104 pool at that cost, and queued for Xero. The sterling valuation is captured here because it cannot be reconstructed accurately afterwards, and it is the figure VAT is due on.

Hold the funds at any point. Hold or generate a key on a server. Route the payment through an account of ours. Take a fee from the transaction. Swap one asset for another. Each of those would change what Ceodore is in the eyes of a regulator, which is rather the point.

Every asset Ceodore handles is a row describing it: chain, address, symbol, decimals, what it is denominated in, and who issues it. Support for a new coin is an entry in that table. Nothing is compiled in, and no deployment is required to accept one.

The registry carries optional fields for the issuer, its authorisation and a link to the public register entry. They are empty today because nothing qualifies. When a coin does, the merchant-facing marks appear on their own, because the interface renders what is populated rather than what is switched on.

The Bank's regime replaced holding limits with a temporary cap on how much of a coin may be issued, and acknowledges this creates some risk of the secondary price drifting from par. A merchant accepting at face value against a sterling invoice carries that difference. So the registry has a field for a machine-readable par feed, and when an issuer publishes one we can show peg status at the moment of acceptance. We asked the Bank to require that in our response to the consultation.

A sterling-denominated, par-redeemable coin removes the valuation problem almost entirely, because the sterling value of a sterling stablecoin at the point of supply is not in dispute. The accounting layer gets simpler, not harder.

The first authorised sterling coin may well launch on Ethereum or a layer two rather than on Solana. Every chain sits behind the same adapter, so that is an implementation of an existing interface rather than a second product.