The engine reads Spring Boot configuration: the venue.* keys below, from a file of your own or from the environment. A deployment sets the required keys and its secrets; every other key has a working default.

How settings are read

  • From a file of your own, passed at start with --spring.config.additional-location=/etc/nodeasset/engine.yml.
  • From environment variables, by Spring Boot’s usual mapping: VENUE_LEDGER_HOST sets venue.ledger.host, and VENUE_SAGA_PASSWORD sets venue.saga.password.
  • Secrets go in files or a secret store, never in the configuration file: the ledger token or client secret, the database passwords and each webhook’s secret.

What the engine refuses at start

In a deployment the engine checks its configuration before it reaches the ledger or a database, and refuses to start unless:
  • the required keys are set: venue.ledger.user-id, venue.party.id, venue.parties.registrar-id, venue.parties.operator-id, venue.parties.oracle-template, venue.pqs.jdbc-url and venue.saga.jdbc-url;
  • every party is given by its full id, <hint>::<fingerprint>, and no party hint is set. The hints have defaults for development, so set venue.party.hint, venue.parties.registrar and venue.parties.operator to empty;
  • venue.daregistry.serve-locally is false;
  • server.address is a loopback address;
  • neither database password is a default one, such as the engine’s own pqs;
  • venue.ledger.tls is true, unless the Canton node is on the same host (localhost, 127.0.0.1 or ::1);
  • the JDBC URL of a database on another host takes sslmode=verify-full.
It also refuses to start when the API’s access table and the routes it serves disagree, so no route is ever served without its rule.

A minimal deployment

The two passwords come from the environment, as VENUE_PQS_PASSWORD and VENUE_SAGA_PASSWORD.

The ledger

Parties

The engine names the registrar and DA’s operator, and never acts as either. Each asset’s registrar is read off its configuration on the Registry, so a payment asset with its own registrar, such as a bank’s tokenized deposit or a stablecoin, can sit beside the fund.

Databases

A database on another host takes sslmode=verify-full&sslrootcert=<CA file> in its URL.

Settlement, operations and the event feed

The API

A caller over its limit is refused 429 rate-limited, with Retry-After and the problem’s retryAfter: the seconds until its window ends. Every answer to a signed-in caller, the 429 and a 403 included, carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset; a public route and a 401 carry none. The default is far above what a front end, a runner or an integrating system sends, so it stops only a client that loops.

Sign-in

A shared-secret mode exists for development only, and the engine refuses it in a deployment. See Identity provider.

Reconciliation

Outside statements

venue.recon.external.sources[] lists the off-ledger sources that post statements, each one party’s feed of one kind. venue.recon.external.max-body-bytes, 5242880 (5 MiB) by default, is the largest statement read. See NAV feed and oracles for what a source posts.

Webhooks

venue.recon.webhooks[] lists the webhooks control events are posted to, signed:
The engine posts only to public addresses and to the networks in allowed-networks. Private, loopback, link-local and reserved addresses, the cloud metadata services among them, are refused otherwise. The address is checked at every delivery, so a name that later resolves elsewhere is refused there. POST /v1/webhooks adds a webhook while the engine runs, under four eyes, with its key in a file in the secret directory; GET /v1/webhooks lists both kinds.

Distributions, the calendar and policies

Retention

What a pass never deletes is on Audit trail and retention.

The DA Registry

Related: Install · Identity provider · Monitoring