Hosted AEX starters

Hosted AEX starters are report-only. They observe configured sources and produce reports or proposed actions. They have no signer, so a wallet address, a chat instruction or a policy setting does not let a hosted starter sign or submit a transaction.

To run a recipe on your own host instead, start from its source in the starter catalog.

Outputs and observation schedules

These are the defaults. Your instance’s applied schedule and next run time are what it actually uses.

Starter	Useful output	Default observation cadence
Airdrop Scout	Sourced opportunities and supported farm/claim readiness, with explicit unknowns	Every 6 hours
Security Guard	Wallet and chain-specific risks, observed approvals and coverage gaps	Every 6 hours
Gem Hunter	Screened candidates with source evidence and refusal reasons	Every 6 hours
DCA Accumulator	A screened recurring quote plan, without a purchase or cost-basis update	Every 24 hours
Privacy Guard	Wallet-linkability findings with history and source limitations	Every 24 hours
Gas & Claims Reminder	Observed gas conditions and claimable-entitlement evidence	Every hour

Airdrop Scout uses the recipe slug autoresearch. Airdrop Farmer and Claim Watch are not available as separate hosted starters.

From Airdrop Scout recipe v0.4.2, each Merkl candidate has a sourceActionUrl. It is the link the provider supplied, not a verified official site. The report states the link type, its verification status and what is unknown about the project’s identity and safety. Check the project’s domain yourself before connecting a wallet. Earlier reports call this field officialActionUrl; that name was never a verification claim.

From Gas & Claims recipe v0.4.1, each gas observation names the block number, block hash, block time and read time. Stale or changed block evidence does not trigger an alert. A watched wallet below its gas threshold is reported as context, not as a request to fund the agent.

The runtime guide in your instance shows which recipe version it runs.

Choose a useful cadence

Run frequently while you set an agent up, to surface failures early. Once it behaves reliably, choose a cadence that matches how fresh the information needs to be and what each run costs. A run that finds nothing new still records what it checked, and does not need to notify you.

Observation cadence, notification cadence and transaction permissions are separate settings. Asking for a daily report does not authorize a daily purchase.

Change the schedule

Send the agent a schedule command in chat:


run every 6 hours
please set your schedule to daily

Intervals range from five minutes to seven days. Send a schedule change as its own message. Questions such as “why do you run daily?” and requests that combine a schedule change with other changes leave the schedule as it is.

The reply says whether the new schedule is saved or already applied to the running agent. A saved schedule takes effect once it is applied. Older runtimes do not support chat scheduling, so confirm the applied schedule and next run time after sending a command.

Find the matching guide

Each hosted runtime ships its starter guides at:


/opt/aex/guides/<recipe-slug>.md
/opt/aex/guides/manifest.json
/opt/aex/runtime-build-ref

manifest.json lists each guide’s hash and default schedule. runtime-build-ref identifies the build. The guides update with the runtime. Notes in /opt/data persist across upgrades and can describe older behavior. Runtimes built before the guide bundle do not have these files.

Before spending

Hosted starters have no signer. Spending needs a separate adapter, authorization from the wallet’s controller, signing credentials isolated from the agent, and an independent check of each result. A proposed action, dry run or local test receipt is not a live transaction.

Check a transaction by its hash, its receipt and finality, and its effect on the protocol: a revoked allowance reads zero afterwards. If the response is lost after broadcast, look up the original transaction instead of sending it again.

Publish a custom agent

Contribute a recipe through the public Agent Exchange repository . Its recipe contribution guide covers the proposal, directory layout, safety requirements and review. Open an issue before starting a substantial port.

A submission describes the agent’s output, required permissions and supported networks, and includes its implementation, configuration, tests and recovery steps. Review, publication and hosted deployment are separate steps. A merged recipe is not deployed, and a manifest grants no signing authority.