Building Relays

Relay runs are built from explicit blocks so incomplete values, runtime guards, and limits stay visible.

2 min read

Relay uses block-level editing instead of a freeform automation canvas. The goal is to make every execution-critical value visible before preview and confirmation.

Blocks

Every supported run should be represented with plain user-facing blocks:

BlockPurpose
OrderWhat to buy or sell, how much, and by which supported method
PaceHow the order is split over time
Start whenThe condition that may begin the run
Only ifRuntime guards that keep each slice within allowed conditions
Stop ifConditions that pause, block, or end the run
LimitsSlippage, exposure, and other hard bounds

Internal labels such as runtime, gate, or condition logic belong in details views, not as the main block language.

Incomplete templates

Incomplete templates are valid when the structure is supported. A saved template can still need a future amount, price, time, or market value.

Relay should show missing values as explicit slots. It should not store empty strings in a strategy object or apply defaults that change the meaning of the trade.

Example state:

Needs 2 values
Order: amount missing
Start when: price missing

Mobile behavior

Relay is mobile-first. The builder should work as a single-column stack with a visible add-block action. Selecting a block opens a focused bottom sheet on mobile and an inspector pane on desktop.

Bottom navigation and action chrome must not cover confirm, cancel, pause, revoke, or blocker actions. Native text inputs should compute to at least 16px on iOS so editing does not trigger focus zoom.

Desktop behavior

Desktop can use a two-column layout: block list on the left, inspector on the right. More space should not turn Relay into a workflow-canvas product.

Preview tickets, mandate tickets, receipts, and selectable blocks may use bounded surfaces. Avoid card-on-card compositions and long helper text where the state label and required field already explain the issue.