Digital asset platforms, built where a defect is a theft rather than an outage.

Regulatory position and the custody question

Whether you hold customer assets is the first question and it decides everything after it. A platform where users retain their own keys is a software product with a support obligation. A platform holding assets is a custodian, which in most jurisdictions means licensing, capital requirements, segregation rules and an audit regime that resembles financial services rather than technology.

Jurisdiction compounds it. Registration requirements differ sharply between markets, several restrict specific activities outright, and the answer changes what you can list, who you can serve and where your entity should sit.

The output is a written position naming the custody model, the licences you hold or are pursuing, the markets you will serve and the assets you will support, because that last one carries its own regulatory weight.

Chain selection and contract architecture

Which chains you support is a product decision with heavy engineering consequences. Each brings its own finality assumptions, fee behaviour, node requirements and failure modes, and supporting four is considerably more than four times the work of supporting one.

Where contracts are involved, upgradeability is the decision that deserves the most thought. An immutable contract cannot be fixed if it is wrong. An upgradeable one introduces an administrative key that is itself the largest attack surface on the platform, and users will reasonably ask who controls it.

Reorganizations and finality are not theoretical. A deposit credited before finality can be reversed by the chain itself, and confirmation thresholds are set per asset with real money behind the judgement.

Key management, and the hot wallet as accepted loss

Custody engineering is the discipline this sector actually runs on. Keys are split across signers, cold storage is genuinely offline, and the hot wallet holds only what you are prepared to lose in a total compromise, because that is the honest way to size it.

Withdrawal is where the controls concentrate: allow-listed addresses, thresholds requiring additional approval, delays on first withdrawal to a new address, and velocity limits that catch a drained account before the balance follows. Every one of those costs user convenience and every one has prevented a real loss somewhere.

Signing procedure is an operational design problem rather than a code one. Who can initiate, who approves, what happens when a signer is unavailable, and how the process survives a person leaving the company.

The engine: matching, liquidity or protocol logic

What sits at the centre depends on what you are building. A centralized exchange needs a matching engine with deterministic price-time priority and a ledger the engine cannot disagree with. A decentralized one needs pricing logic that behaves under adversarial conditions rather than only in normal markets.

Ledger separation matters more here than almost anywhere. The engine matches, the ledger records, and the two reconcile continuously, because a platform where the trading system is also the accounting system cannot prove its own solvency.

For marketplaces and launchpads the equivalent is escrow and settlement: who holds the asset during a trade, what releases it, and what happens when one side disappears mid-transaction.

Audit, and what an audit does not cover

External audit is expected in this sector and it is worth understanding precisely what it buys. An audit examines the code presented at a point in time. It does not cover what you deploy afterwards, your key management practice, your operational procedures or the economic design of the system, and most incidents involve at least one of those.

We build to be auditable, which means the contract surface is kept small, the privileged functions are few and obvious, and the deployment that goes to production is verifiably the artefact that was reviewed. Our platforms arrive with a VAPT and compliance document so the external review starts from a documented baseline rather than a blank page.

Bug bounties and monitoring belong here too, because the interesting attacks arrive after launch rather than before it.

Identity, screening and the travel rule

Compliance in digital assets has converged toward financial services faster than many operators expected. Identity verification, sanctions screening, transaction monitoring and originator information accompanying transfers above a threshold are now standard expectations rather than differentiators.

Chain analytics adds a dimension traditional finance lacks: an address can be screened against known illicit activity before a deposit is credited, which is a genuinely stronger control than anything available on a bank transfer. Using it well means deciding what happens on a match, and having that answer before the first one arrives.

Where your platform is non-custodial, obligations differ, and getting that distinction wrong in either direction is expensive.

Launch, incident readiness and day two

Launch limits are a security control rather than a growth constraint. Deposit and withdrawal caps for the first period, a small asset list, and monitoring watched by people rather than by alerts alone, because the first weeks are when a platform is probed hardest.

Incident response is designed before it is needed: who can pause what, how a suspicious withdrawal is held, how customers are told, and who speaks publicly. In this sector an incident is public within minutes whether or not you announce it. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.