Complete guide to KWALA's YAML-based scripting language for Web3 automation
KWALA Scripts are YAML-based declarative workflows used to define off-chain logic that reacts to on-chain events, time-based triggers, or Web2 inputs. These scripts are executed by the KWALA network to automate backend logic — without requiring traditional servers, polling mechanisms, or custom infrastructure.
Identifier for the workflow
Execution mode (parallel or sequential)
The steps to be executed
The steps to be executed
Before you can create and run KWALA workflows, you need to set up your wallet and obtain KWALA credits. Here's a step-by-step guide to get you started:
KWALA integrates seamlessly with KALP Wallet to manage your workflow executions and payments.
KWL-YourKalpAddress-CC
KWALA uses a credit-based system to execute your workflows. Here's how to add credits to your account:
Pay with USDT to purchase KWALA credits
Credits are added to your KWALA address immediately
Keep your KWALA address topped up to ensure uninterrupted workflow execution. You can recharge at any time through your KALP Wallet.
Every time you run a KWALA workflow, credits are automatically deducted from your KWALA address:
Credits are deducted based on the complexity and resources used by your workflow
Failed workflows may still consume minimal credits for processing
You can monitor your credit balance and usage through your KALP Wallet
Low balance notifications help you stay ahead of your credit needs
Your KALP Wallet Address:
0x742d35Cc6e9A5f1e7A0e6FD4C8b2Bc3F5d9E1234
Generated KWALA Address:
KWL-0x742d35Cc6e9A5f1e7A0e6FD4C8b2Bc3F5d9E1234-CC
This KWALA address is where you'll send USDT to purchase credits and where credits will be deducted for workflow execution.
A descriptive name for the workflow
Should be unique within your project or environment
Defines whether actions are executed in parallel or sequential order.
parallel sequential This is where you define what the workflow actually does — deploying contracts, calling functions, sending tokens, or invoking APIs.
| Action Fields Explained: | ||
|---|---|---|
| Field | Required | Description |
| Name |
|
The unique identifier for the API resource |
| Type |
|
Type of action: deploy, call, api |
| APIEndpoint |
|
URL if making an API call (used when Type is api) |
| APIPayload |
|
Request body for the API call |
| Bytecode |
For Deploy
|
Contract bytecode (hex string) when deploying |
| EncodedABI |
|
ABI-encoded constructor or function call |
| InitializationArgs |
For Deploy
|
Arguments to pass into the constructor |
| TargetContract |
For Call
|
Address of the smart contract to interact with |
| TargetFunction |
For Call
|
Function name (e.g., transfer, mint) |
| TargetParams |
For Call
|
Parameters for the function call |
| ChainID |
|
EVM Chain ID where the action will be executed |
| Metadata |
|
Optional metadata or tags |
| RetriesUntilSuccess |
|
Number of retries until success (default is 0) |
This section defines when and how the workflow is initiated.
| Trigger Fields Explained: | ||
|---|---|---|
| Field | Required | Description |
| Name |
|
The unique identifier for the API resource |
| Type |
|
Type of action: deploy, call, api |
| APIEndpoint |
|
URL if making an API call (used when Type is api) |
| APIPayload |
|
Request body for the API call |
| Bytecode |
For Deploy
|
Contract bytecode (hex string) when deploying |
| EncodedABI |
|
ABI-encoded constructor or function call |
| InitializationArgs |
For Deploy
|
Arguments to pass into the constructor |
| TargetContract |
For Call
|
Address of the smart contract to interact with |
| TargetFunction |
For Call
|
Function name (e.g., transfer, mint) |
| TargetParams |
For Call
|
Parameters for the function call |
| ChainID |
|
EVM Chain ID where the action will be executed |
| Metadata |
|
Optional metadata or tags |
| RetriesUntilSuccess |
|
Number of retries until success (default is 0) |
Always validate YAML for indentation and formatting
Test scripts using the KWALA Playground before deployment
Use parallel for independent tasks and sequential for dependent ones
You can combine Web2 and Web3 actions in one script
Keep API secrets and keys secure — never hardcode sensitive data in public workflows
Environment variables for secrets and keys
Conditionals (if/else logic)
Input forms for user-triggered workflows
Reusable components and template libraries