Developers

Status: Not decidedStatus: Built, runs on simulatorStatus: Coming soon

Developing against Merces starts with the pinned protocol model and the boundary between onchain execution, backend integration, and the application.

These pages describe Stage 1 at bafe1fb and the active Stage 2 source at ec88c4b. A newer checkout does not silently change the baseline used by the examples and claims.

Start with the stable explanations

Read the architecture to see which layer builds transactions and which one changes chain state. Then use the reference math, parity vectors, and proof circuit pages to understand the calculation and test boundaries.

The generated program, contract, event, and status references expose the interfaces selected from Stage 1. They are source references, not evidence of a deployed instance.

Separate implementation from release readiness

The backend’s ChainPort separates current reads, an ordered event stream, unsigned transaction building, and submission. The simulator implements the same boundary, but a simulator result does not establish that an adapter has complete transaction builders or event decoding for an external chain.

The integration report distinguishes complete vector runs, partial runs, waivers, and unresolved differences. Keep those labels when reporting your own work. A test that stops at an acknowledged unsupported operation does not exercise what would have happened afterwards.

Why some guides remain drafts

The API and deployment guides are held while the required API_CHANGELOG.md and DEPLOY_DAY.md are missing and the integration conditions remain unmet. Their preparation material identifies files and checks; it does not claim an executed tutorial.

What can go wrong

Mixing source baselines can pair a builder with incompatible schemas, proofs, or expectations. Copying a simulator result into a deployment claim can also conceal an unfinished adapter. Record the source, backend, and test scope together.