Inputs

Inputs are the values a buyer provides for each run, such as a token address or a wallet. This page covers declaring inputs and analysis chains in the workflow builder, how inputs are validated, and what buyers see. It is for creators building workflows; template agents have fixed inputs.

Declare an input#

Inputs live in Settings → Inputs ("What a buyer provides for each run"). The Inputs step on the canvas summarises them and links there with Add inputs in Settings or Edit inputs in Settings.

1. Type a New input name, for example token.
2. Choose its Type.
3. Choose Add input.
4. On the new row, add a Description shown to buyers (up to 500 characters) and tick or clear Required. New inputs start as required.

To remove an input, use the bin button on its row. Steps that still use it then report "The input "Name" no longer exists. Choose another value."

A workflow can declare up to 32 inputs.

Input types#

Address inputs matter beyond validation: with the default address scope, a run's tools may read only addresses supplied as inputs (plus fixed platform contracts a tool is reviewed to read). See Run budget, limits and rights.

Name inputs carefully#

• The builder turns the name into a camelCase key: "token address" becomes tokenAddress.
• Inputs are public research parameters, never secrets. Names that look like credentials (containing words such as privateKey, secret, password, passphrase, mnemonic, seedPhrase, apiKey, accessToken, authToken or credential) fail validation, for example "Input apiKey looks like a credential. Buyer inputs cannot collect secrets; declare a secret reference instead."
• Buyers see a label made from the name. Common names get a fixed label:

Any other name is shown in words: minimumAmount becomes "Minimum amount". Choose names that read well, and put anything else a buyer needs to know in the description.

Analysis chains#

Settings → Analysis chains sets the networks the workflow can analyse: Solana, Ethereum, Base and Robinhood Chain. A new workflow starts with Ethereum ticked.

• "Every step must work on every chain you tick; each run uses one of them." A tool that does not support a ticked chain is reported by name, for example "Token metadata does not run on Solana."
• The buyer chooses one of your chains for each run, under Analysis chain. Solana is listed first when it is one of them.
• Only the public web reader supports both Solana and EVM chains, so in practice a workflow analyses either Solana or one or more EVM chains.
• Match address types to chains. An EVM address input on a Solana run is refused with "name is an EVM address but the selected chain is Solana"; a Solana address on an EVM run with "name is a Solana address but the selected chain is EVM".

Use inputs in steps#

Wherever a step needs a value, choose Input: name in its value picker. Typical uses:

• the address argument of a data step, for example the token setting of Token metadata;
• the checked value of a condition, or a value passed to AI analysis;
• a finding value, to echo what the buyer asked about.

A finding whose value comes straight from an input is shown in the report as "(from input, not observed)" and cites no evidence. See Report sections and findings.

What buyers see#

On the purchase form of your listing, buyers see:

1. Analysis chain, listing the chains you ticked.
2. One field per input. Optional inputs show "(optional)". Address fields show a 0x… or "Base58 address" placeholder; True or false inputs are a checkbox.
3. Your description under the field, unless it only repeats the label.

The listing page also lists your inputs, so buyers can see what the agent needs before they run it. Test your inputs the same way on the test page, which uses the same labels.

Validation at run time#

A run is refused before any read if an input does not match:

Related pages#

• Data steps and approved tools
• Conditions and transforms
• Test privately