22.4 Latency-sensitive execution path

[determined-001]

Labels: type:feature area:workers type:perf
Milestone: Phase 4 - Workers W4: latency-sensitive and vault
Effort: High
Depends on: 21.3, 22.3

Description

Enables the tier 21.3 defined and disabled. For copy-trading and liquidations,
"late" means the opportunity is gone - and §C.7 is blunt about the consequence:
catching the miss costs the same as running primary infrastructure. Earn the way
here; do not sell it before the infrastructure exists.

Acceptance criteria

• Hot-path execution: pre-simulated, pre-signed where safe, submitted within a
  declared ledger budget
• Hot standby so a single process restart does not blow the latency budget
• Latency budget measured end to end - condition observed to transaction
  submitted - and published on the scorecards
• The tier's cost is measured through 21.2 before the tier is enabled
• Enabling the tier is a documented, reversible operational decision
• Backpressure under burst load handled per 13.1 Backpressure and bounded memory under burst load #921 rather than a parallel
  mechanism

Implementation notes

1. Measure before enabling. The tier's whole risk is promising a latency the
   infrastructure has not demonstrated.
2. "Pre-signed where safe" needs a written boundary: pre-signing an action whose
   parameters depend on observed state is not safe, and the code should make the
   distinction structural.
3. Coordinate with 13.1 Backpressure and bounded memory under burst load #921 (backpressure and bounded memory under burst load) - the
   hot path is exactly where an unbounded queue turns latency into an outage.

Affected files

• packages/worker-core/src/hotPath/
• packages/worker-core/src/backstop/tiers.ts
• packages/pulse-core/src/EventEngine.ts

[Kingsilva36]

@Kingsilva36 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would love to work on this professionally, please assign it to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Kingsilva36 to this issue.

[Gentleslyl2006]

@Gentleslyl2006 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would love to Fix this Issue and I will be dropping PR immediately

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Gentleslyl2006 to this issue.

[Peace-001]

@Peace-001 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Good day maintainer i would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Peace-001 to this issue.

[ibochivincent-lang]

@ibochivincent-lang has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #1071 because latency-sensitive workers such as copy-trading and liquidation jobs are only useful when they can react quickly enough for the opportunity to still exist. The implementation therefore needs to prove its latency before the tier is enabled, rather than simply adding a faster execution path without measurement.

I will first review the existing worker architecture, especially the work from #21.3 and #22.3, along with packages/worker-core, packages/pulse-core/src/EventEngine.ts, and the current backstop tier definitions. I will also review the backpressure work from #921 so the hot path uses the existing bounded-queue strategy instead of introducing another mechanism.

I will then build the hot-path execution flow with pre-simulation and pre-signing only where it is safe. The code will make the safety boundary explicit: actions whose parameters depend on newly observed chain state must not be blindly pre-signed, while genuinely safe reusable work can use pre-signing.

The execution path will also include a hot standby so a single worker process restart does not automatically consume the entire latency budget. I will keep the standby behavior consistent with the existing worker model rather than creating a separate execution architecture.

A major part of the work will be measurement. I will record the end-to-end latency from condition observation through transaction submission, including the important stages between those points, and expose the measurements through the existing scorecard/observability mechanisms.

I will also make the tier's infrastructure cost measurable through the existing #21.2 work before enabling it. The implementation will treat activation as an explicit operational decision, with documentation covering how to enable, disable, and roll back the tier safely.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ibochivincent-lang to this issue.

[drips-wave]

Congratulations, @ibochivincent-lang! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @ibochivincent-lang: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊