Settlement windows and grade horária
Núclea’s SLC settles on rigid daily windows set by its grade horária. Lerian SLC evaluates each window as OPEN, PRE_CUTOFF, or CLOSED, and gates dispatch on the result. The rail holds a QUEUED operation outside its window and dispatches it when the window opens. This avoids Núclea’s out-of-window rejection (ESLC0029). Lerian SLC emits
schedule.cutoff_approaching as a window approaches its cutoff, 30 minutes ahead by default. Use GET /v1/schedule to read the windows and the credit dispatch window that the rail enforces.
- Queue and retransmit. An operation stays CREATED until an operator requeues it into the dispatch queue. A retransmit resubmits one QUEUED operation.
GET /v1/participants/{id}/operational-status to read that status and whether the hold applies.
Certificates and custody
Lerian SLC delegates signing to a custody backend: a software key, a PKCS#11 HSM, or AWS KMS. The signing credential is an ICP-Brasil certificate with an RSA key of at least 2048 bits.
- SaaS deployments lock custody to AWS KMS. The rail imports the client’s wrapped key material and never receives the signing private key in cleartext.
- Validity. Lerian SLC refuses to sign with a certificate outside its validity window.
- Rotation. Lerian SLC reads the active signing certificate on each signature, so a rotation takes effect on the next one. The mTLS client certificate loads at startup, so its rotation needs a restart.
- Expiry alerts escalate at 30, 15, 7, and 1 day before expiry, as
certificate.expiringevents, whenSCHEDULE_CERT_EXPIRY_ENABLEDistrue.
Contingency and recovery
- Dead-letter queues. The rail parks an inbound RSFN or Lerian SILOC message that it cannot process. A parked message stays on the queue for 30 days.
GET /admin/dlq/{queue}lists the parked messages, and a replay reprocesses one. A replay of a message already processed changes nothing. - Recovery drains. The dispatch, forward, repoll, status-relay, and reprocess endpoints re-run the rail’s own outbound and return work without waiting for the next tick.
- Retry. A retry resubmits a REJECTED operation as a new operation linked to the original. An operation that the IF Domicílio refused on D+1, after it settled, is not retryable.
- Parked operations. When consecutive counterpart refusals exhaust an outbound operation’s transmit-attempt budget, the rail parks the operation and alerts instead of retrying forever. The un-park endpoint returns it to the eligible backlog, so the next tick re-drives it. It resets the attempt counter, so a recovered operation receives a full budget. Without a fix for the cause, it parks again after that budget is exhausted.
- Cancellation repasses. When the rail cannot determine whether a cancellation relay to the credenciadora reached Núclea, it keeps the relay blocked. After you establish the outcome, the resolve endpoint records it:
CONFIRMEDkeeps the relay blocked, andABANDONEDmakes it relayable again. - Failed deposits.
GET /v1/funding/acks?result=FAILEDlists the deposits that the client reported as failed.
Reconciliation
- Per operation. The rail tracks each operation by its NUliquid. A lookup by NUliquid reads the local record. If that record does not exist, the lookup asks Núclea. This needs the participant’s ISPB and a NUliquid at most 30 days old.
- Against Núclea. The reconcile endpoint asks Núclea for an operation’s settlement status (SLC0908) and records the answer. It moves an operation only from FORWARDED to CONFIRMED or from CONFIRMED to SETTLED, and it requires a reason.
- Per clearing cycle. The rail tracks the clearing position per cycle and reports a bilateral divergence. It flags a D+1 confirmation that also reports a divergence in the settled value.