A programmable workflow is only useful if the chain can tell you where it is, who may execute it, and what happened next.

Velocity Scripts now have that state model. A script can create a typed intent, place it in a pending queue, expose it through generated query services, and let the relayer process it against an approved execution path. Status is queryable, so clients do not have to infer progress from a local job runner.

The execution path

The chain stores the intent before external work begins. That gives the relayer a concrete queue and gives users a record they can inspect. Pending and status-filtered queries make recovery less fragile: a restarted processor can ask the chain what remains instead of trusting its own memory.

We also wired the intent methods through the EVM precompile surface and migrated the module to generated protobuf services. The result is one typed contract across Cosmos messages, queries, EVM calls, and relayer processing.

There is a useful boundary here. Velocity does not mean arbitrary code gets authority over funds. Scripts enter known adapters and the chain records the intent lifecycle. Permissions and module-specific checks still decide what can execute.

What this enables

Wallets can submit a workflow and follow its state. Relayers can resume pending work after a restart. Agents can use the same surface without receiving a private bypass around chain permissions.

That is the part we care about: automation that remains observable when the happy path stops being happy.

Source record