Architecting Permissionless Cross-Chain Automation

Automation becomes much harder when the action should happen across blockchains.

A conventional automation service can hold credentials, maintain a database of jobs, execute transactions and retry failures. That is relatively straightforward because the automation service controls the execution environment.

The architectural problem changes when the goal is to make automation permissionless and non-custodial.

The automation layer should not need to own the user’s assets or private keys. It should be able to interpret an intent, determine when the required conditions are met, and coordinate execution across chains while relying on the underlying blockchain security model.

That was the architectural direction behind Intento.

From transactions to intents

A transaction says:

Execute this specific action.

An intent describes:

This is the outcome I want, subject to these conditions.

That distinction shaped the architecture.

Instead of building a conventional off-chain automation service, Intento was implemented as an Intent-centric Automation module for the Cosmos SDK.

The intent lifecycle therefore lives in blockchain state rather than primarily in a centralized scheduler or external database.

User / Application
        │
        │ create intent
        ▼
┌──────────────────────┐
│ Cosmos SDK           │
│ Intento Module       │
│                      │
│ Intent state         │
│ Conditions           │
│ Authorization        │
│ Execution state      │
└──────────┬───────────┘
           │
           ▼
      Executor(s)
           │
           ▼
      Blockchain

That was a deliberate architectural choice.

The blockchain becomes the authoritative state machine for the intent rather than merely the settlement layer underneath an off-chain application.

Concrete architectural decision #1: make the intent layer on-chain

The first major decision was to make Intento an on-chain module rather than a centralized execution service.

That means the core intent state, lifecycle and execution rules are part of the chain’s state machine.

The benefit is verifiability and deterministic state transitions.

It also changes the failure model.

A centralized service failing should not make all intents disappear or become inaccessible. Intent state remains part of the chain, and execution can be performed independently.

The trade-off is that logic has to fit blockchain execution constraints.

The module therefore needs deterministic behaviour and cannot depend on arbitrary off-chain computation during consensus execution.

Concrete architectural decision #2: use a Cosmos SDK module

Rather than creating an entirely separate automation network and execution stack, Intento was designed directly as a Cosmos SDK module.

That gave the system access to the existing blockchain primitives for:

• transaction handling;
• state management;
• authorization;
• governance;
• event emission;
• and chain-level execution.

It also meant the intent engine became a composable blockchain capability rather than a separate SaaS system sitting beside a blockchain.

The architectural boundary was intentionally narrow:

Cosmos SDK Chain
┌────────────────────────────────────┐
│                                    │
│  Intento Module                    │
│                                    │
│  intents → conditions → execution │
│                                    │
└────────────────────────────────────┘

The module owns intent orchestration.

The underlying blockchain remains responsible for consensus and state transition.

Concrete architectural decision #3: IBC as the cross-chain boundary

Cross-chain execution was designed around IBC rather than a proprietary bridge layer.

That decision was important because the architecture needed to remain native to the Cosmos ecosystem and avoid making Intento responsible for reinventing cross-chain transport.

The resulting model became:

             Intento
                │
                │ IBC
        ┌───────┴────────┐
        ▼                ▼
     Chain A           Chain B
        │                │
        ▼                ▼
   Remote action    Remote action

IBC handles communication between chains.

Intento handles the intent and execution coordination.

This separation matters because transport and intent semantics are different architectural concerns.

Concrete architectural decision #4: Interchain Accounts for remote execution

IBC provides communication, but communication alone does not execute arbitrary actions on another chain.

For that, Intento used Interchain Accounts (ICA).

This created a useful separation:

Intento decides what should happen.

IBC transports the cross-chain message.

The Interchain Account performs the action on the destination chain.

Intento
   │
   │ intent execution
   ▼
IBC channel
   │
   ▼
Interchain Account
   │
   ▼
Destination chain
   │
   ▼
Actual state change

This avoided creating a separate private-key custody model for every destination chain.

The destination chain still performs the actual state transition according to its own rules.

Concrete architectural decision #5: use AuthZ instead of custody

The system also needed a way to allow automation to act on behalf of users without giving an automation service unrestricted control of their assets.

The architecture therefore used Cosmos AuthZ grants.

Instead of:

User
  │
  │ private key
  ▼
Automation service

the model is closer to:

User
  │
  │ constrained authorization
  ▼
Authorized execution
  │
  ▼
Intento
  │
  ▼
Blockchain action

This creates an explicit authorization boundary.

The automation layer gets authority according to the granted permissions rather than taking custody of the user’s keys.

That distinction is fundamental to the trust model.

Concrete architectural decision #6: separate executor identity from execution rights

A permissionless system should not depend on one trusted backend being the only entity capable of execution.

Intento was therefore designed so that execution can be performed by independent executors.

The executor is not the source of truth for the intent.

The executor observes eligible intents and submits the required transaction.

              On-chain intent
                    │
           ┌────────┼────────┐
           ▼        ▼        ▼
       Executor A Executor B Executor C
           │        │        │
           └────────┼────────┘
                    ▼
              Execute intent

This separates:

who is allowed to execute

from

who happens to submit the transaction.

That is a major difference from a traditional centralized automation worker.

Concrete architectural decision #7: keep the execution model VM-agnostic

Another architectural goal was to avoid making the intent abstraction dependent on one specific virtual machine.

The intent layer therefore sits above chain-specific execution:

Intent definition
       │
       ▼
Intent execution model
       │
       ├──────────► Cosmos / IBC / ICA
       │
       └──────────► Other execution environment

The purpose of this abstraction is not to make every chain identical.

It is to keep the intent model and orchestration layer separate from the mechanics of a particular execution environment.

Chain-specific behaviour remains below the abstraction boundary.

Concrete architectural decision #8: keep failure state explicit

Cross-chain automation is inherently asynchronous.

A transaction can be accepted on the source side while the destination chain is delayed, unavailable or returns an error.

Intento therefore models execution as a lifecycle rather than treating a transaction submission as the entire operation.

Created
   │
   ▼
Authorized
   │
   ▼
Eligible
   │
   ▼
Executing
   │
   ├──────► Failed / retryable
   │
   ▼
Completed

The important architectural principle is that failure is part of the state model.

That is especially important in cross-chain systems because the absence of a successful destination transaction cannot simply be interpreted as “the job failed and can be forgotten.”

What this architecture deliberately avoids

The resulting design deliberately avoided several patterns:

Custodial automation — no central service holding users’ private keys.

Centralized job state — intent state is not dependent on one external scheduler.

Proprietary cross-chain transport — IBC provides the primary Cosmos interchain communication mechanism.

Direct coupling to one VM — the intent model remains above the chain-specific execution layer.

Single trusted executor — execution can be permissionless rather than tied to one backend.

These choices all follow from the same architectural objective: reduce unnecessary trust assumptions while retaining deterministic execution.

The trade-off

This architecture is not simpler than a conventional automation service.

It is more complex.

You inherit the realities of blockchain systems:

• asynchronous execution;
• transaction finality;
• interchain communication;
• authorization semantics;
• deterministic execution requirements;
• and more complicated failure handling.

The architecture is therefore justified only when those properties actually matter.

That was the core design question.

Not:

“Can we build an automation engine on-chain?”

But:

“Which parts of automation genuinely benefit from being on-chain, permissionless and non-custodial?”

The broader lesson

The strongest architectural decisions were not individual technologies.

IBC, ICA, AuthZ and the Cosmos SDK were useful because they mapped cleanly onto distinct responsibilities.

                Intento
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
       Intent   AuthZ     Executor
          │        │        │
          └────────┼────────┘
                   ▼
                  IBC
                   │
                   ▼
                 ICA
                   │
                   ▼
             Target chain

The resulting architecture separates intent, authorization, transport and execution instead of putting all four responsibilities into one trusted service.

That separation is what makes the system composable and permissionless.

Key insight: The important architectural decision in decentralized automation is not putting a scheduler on a blockchain. It is deciding which responsibilities belong on-chain, which belong to the interchain layer, and which can remain permissionless execution infrastructure.