Architecture across the build layers

Status: Built, runs on simulatorStatus: Coming soonStatus: Built, runs on simulator

Merces separates the application boundary, the backend’s coordination work, and the protocol state executed through a selected chain implementation.

The diagram shows the integration boundary, including unfinished adapters. It does not establish an available application or deployment.

Read and write paths

Services depend on ChainPort, whose interface offers current-state reads, resumable event reads, unsigned user transaction construction, signed transaction submission, and service-role submission. This keeps the service boundary distinct from a particular chain’s instruction or transaction format.

The indexer projects finalised events into a read model and advances its cursor in the same database transaction. Lists and histories can therefore come from indexed state, while precise current values may be read through the chain port. A displayed history and a fresh chain read need not have the same observation time.

Where the simulator fits

The simulator is another implementation of the port. Automatic selection can fall back to it if a chain adapter is unavailable. The EVM adapter now marks its generated builders, native reads and canonical event stream as wired. Live deployment configuration and conformance are separate checks; record the selected mode in every test result.

Evidence has a separate route

An issuer’s device prepares income evidence. The isolated report verifier checks its input transiently, while accountant-review material is encrypted for the chosen attestor. The read model should not become a convenient copy of raw income evidence.

What can go wrong

A service can correctly use the port while its selected implementation is still a simulator. An indexer can also lag behind a successful transaction. Track the selected mode and the observed state before describing an operation as complete.