Coming Soon - Estimated by the End of March 2026.
# Contact Us ### Decimal Ltd.| Description | URL |
|---|---|
| Website : | https://decimal.at/ |
| Documentation : | https://wiki.decimal.at/ |
| Application : | https://canvas.decimal.at/ |
| Twitter/X : | https://x.com/decimalat |
| Telegram : | https://t.me/decimalat |
| Discord : | https://discord.gg/HW4z6Vuqz4 |
| Youtube : | https://www.youtube.com/@decimalat |
| Github : | https://github.com/decimalat |
| Email : | hello@decimal.at tech@decimal.at |
| Description | URL |
|---|---|
| Twitter/X : | https://x.com/sinha_abhijat |
| Telegram : | https://t.me/sinhaabhijat |
| LinkedIn : | https://linkedin.com/in/abhijatsinha/ |
| Calendar : | https://cal.com/abhijat |
| Email : | abhijat_sinha@decimal.at |
| Tier | Monthly Fee | Included | Best For |
|---|---|---|---|
| Free Starter | $0 | • 1,000 tasks/month• 2 Web2 connectors• Community support | Hobbyists, testing, first workflows |
| Flex Pay-As-You-Go | $0 + usage fees | • $0.10 / 100 tasks• $5 / premium node (Web3, AI, heavy compute)• Carry-over credits | Makers who want to pay only for what they use |
| Pro Builder | $49 | • 50,000 tasks• 10 Web2 connectors• 3 Premium nodes• Email support | Freelancers & small teams running live projects |
| Team Scale | $199 | • 250,000 tasks• Unlimited Web2 connectors• 10 Premium nodes• Priority support | Agencies & startups with multiple active apps |
| Enterprise | Custom | • Unlimited tasks• Custom connectors• SLA + Dedicated support | Enterprises, DAOs, regulated orgs |
If on Flex Pay-As-You-Go → $0.10 × 25 = $2.50 + $5 = $7.50 total. *** #### Example 2: Your team automates 50,000 Discord community alerts + wallet balance trackers. * Fits exactly within Pro Builder plan → $49 flat. ### 5. Upgrades & Downgrades * Upgrade anytime: changes apply immediately. * Downgrade or cancel anytime: unused credits carry over. * No lock-in: you only pay for what you use. ### 6. Why This Matters Decimal’s pricing model keeps you in control: * **No sunk cost risk** – unused credits are never wasted. * Aligned with your growth – start free, pay when you scale. * Ecosystem positive – by choosing across multiple vendors in the drag-and-drop builder, you push the ecosystem to deliver better performance, lower costs, and higher reliability. # Setup Onboarding process... ### Step 1: Setting up the wallets #### 1. Master Wallet
User Wallet for "Connect Wallet"
For common or repeated use cases, native integrations are recommended where available. *** ### Adding Call API to a Workflow 1. Open the Decimal workflow editor 2. Add a Trigger node 3. From Integration, select Call API 4. Connect the Call API node to your trigger\
Once added, the Call API Settings panel opens automatically.  *** ### Module Configuration #### HTTP Method Select the HTTP method for the request. Supported options: * GET – Fetch data * POST – Send data * PUT – Update data * PATCH – Partially update data * DELETE – Remove data
Choose the method based on the API you are calling. *** #### URL Enter the full endpoint URL for the request. **Example**: *
You can: * Enable or disable headers using the checkbox * Edit header values * Remove headers using the ❌ icon * Add additional headers using + Add Header *** #### Request Body The request body is used for: * POST * PUT * PATCH Enter a valid JSON payload. **Example**: { "key": "value" } For GET requests, the request body is ignored.  *** #### Result Variable Name Define the variable name that will store the HTTP response. Default example: *httpResult* This variable becomes available to all downstream nodes in the workflow. *** ### Output & Variables After execution, the response from the API is stored under the specified result variable. Typical response data includes: * Status code * Response body * Headers (if supported)\
**Example usage in downstream nodes:** *httpResult.body* *httpResult.status* This data can be: * Passed to logic nodes (If Else) * Transformed using Run Code * Stored using Set Variable * Used to trigger further actions *** ### Example Workflow Use Case: Fetch data from an external API and process it. Workflow: 1. Trigger 2. Call API 3. If Else (check response) 4. Run Code or Set Variable This allows you to build API-driven workflows without external services or scripts.
# PARTNER: CoinGecko price feed ### Overview The CoinGecko integration allows you to fetch real-time cryptocurrency price data directly inside a Decimal workflow. It is commonly used for price monitoring, automation triggers, reporting, and downstream financial or Web3 actions. This integration works as a node in the Decimal workflow editor and can be connected to any trigger or automation logic. ### Available Modules #### Fetch Token Price Fetches the current price of a selected cryptocurrency using CoinGecko data. This module supports both free and paid CoinGecko API access, depending on your usage needs. *** ### Supported Modes #### Free API (Demo) * Uses CoinGecko’s free demo API * Suitable for testing, prototyping, and low-frequency workflows * Subject to strict rate limits * Uses CoinGecko’s paid API * Higher rate limits * Recommended for production workflows and frequent executions
*** ### Adding CoinGecko to a Workflow 1. Open the Decimal workflow editor 2. Add a Trigger node 3. From the Web3 → CoinGecko section, select Fetch Token Price 4. Connect the CoinGecko node to your trigger\  Once added, the configuration modal will open automatically. *** ### Module Configuration #### Step 1: API Configuration **API Plan** Select the API plan you want to use: * Free – Uses CoinGecko Demo API * Pro – Uses CoinGecko Paid API\
**API Key** * Go to the CoinGecko website and sign in or create an account:[ https://www.coingecko.com](https://www.coingecko.com) * Navigate to the Developer Dashboard to generate your API key:
Example usage in downstream nodes: *coingeckoResult.price* *coingeckoResult.currency* *** ### Example Workflow Use Case: Fetch Bitcoin price and use it in a downstream automation. Workflow: 1. Trigger (manual or scheduled) 2. Fetch Token Price (CoinGecko) 3. Use the price in a notification, condition, or data store This setup allows automated price-based workflows without external scripts.
# PARTNER: 1inch Bridge ### Overview The 1inch Bridge allows you to perform token bridge using the 1inch aggregation protocol directly inside a Decimal workflow. It enables automated, cross-chain token bridge while leveraging 1inch’s routing and liquidity optimisation. This integration is designed for Web3-native workflows where swaps need to be executed programmatically, conditionally, or as part of a larger automation. Common use cases include: * Cross-chain asset movement * Treasury and fund management workflows * Strategy-based DeFi automation *** ### Available Module #### 1inch Bridge Executes a token bridge using 1inch based on the configured source token, destination token, chain, and amount. *** ### When to use 1inch Bridge Use the 1inch node when: * You need to bridge tokens programmatically * Swaps are part of a larger automated workflow * You want best-route aggregation without manual execution * You need cross-chain token movement This node is typically used after wallet connection and before downstream actions like transfers or contract calls. *** ### Adding 1inch to a Workflow 1. Open the Decimal workflow editor 2. Add a Trigger node 3. From Web3, select 1inch Bridge 4. Connect the node to the trigger or previous step Once added, the 1inch Settings panel opens automatically. *** ### Module Configuration #### From Token Select the source token to bridge from. Example: *ETH (Ether)* Note: Native tokens (e.g. ETH) may not be supported as source tokens directly. In such cases, use the wrapped version (e.g. WETH). *** #### Destination Chain Select the destination chain for the bridge. Example: *Base* For cross-chain swaps, the destination chain must be different from the source chain. *** #### To Token Select the destination token to receive. Example: *WETH (Wrapped Ether)* *** #### Amount Enter the human-readable amount to bridge. Example: *0.1* Decimal automatically handles token decimals during execution. This field is required. *** #### Recipient (Optional) Specify a recipient wallet address for the bridge tokens. * If left empty, tokens are received in the connected wallet * Useful for routing funds to external wallets or contracts
Example: *0x...* *** ### Output & Execution When executed, the 1inch node: * Fetches the optimal bridge route * Executes the bridge onchain * Returns execution details to the workflow Typical output includes: * Transaction hash * Source and destination tokens * Amounts swapped * Execution status These results can be used in downstream nodes for validation, logging, or follow-up actions. *** ### Example Workflow Use Case: Bridge ETH to WETH automatically. Workflow: 1. Trigger 2. Wallet Connection 3. 1inch Bridge 4. If Else (validate execution) 5. Transfer or store result This enables fully automated swap workflows without manual intervention. *** **Here are the official 1inch references** * 1inch Documentation:[ https://docs.1inch.io](https://docs.1inch.io) * 1inch Developer Docs (API & Protocol):[ https://portal.1inch.dev](https://portal.1inch.dev) * 1inch on X (Twitter):[ https://x.com/1inch](https://x.com/1inch) # PARTNER: LayerZero Bridge ### Overview The LayerZero Bridge allows you to perform token bridge using the LayerZero core asset transfer protocol directly inside a Decimal workflow. It enables automated, cross-chain token bridge while leveraging LayerZero’s routing and liquidity optimisation. This integration is designed for Web3-native workflows where cross-chain asset bridging needs to be executed programmatically, conditionally, or as part of a larger automation. Common use cases include: * Cross-chain asset movement * Treasury and fund management workflows * Strategy-based DeFi automation *** ### Available Module #### LayerZero Bridge Executes a token bridge using LayerZero based on the configured source token, destination token, chain, and amount. *** ### When to use LayerZero Bridge Use the LayerZero node when: * You need to bridge tokens programmatically * Bridges are part of a larger automated workflow * You want best-route aggregation without manual execution * You need cross-chain token movement This node is typically used after wallet connection and before downstream actions like transfers or contract calls. *** ### Adding LayerZero to a Workflow 1. Open the Decimal workflow editor 2. Add a Trigger node 3. From Web3, select LayerZero Bridge 4. Connect the node to the trigger or previous step Once added, the LayerZero Settings panel opens automatically. *** ### Module Configuration #### From Token Select the source token to bridge from. Example: *ETH (Ether)* Note: Native tokens (e.g. ETH) may not be supported as source tokens directly. In such cases, use the wrapped version (e.g. WETH). *** #### Destination Chain Select the destination chain for the bridge. Example: *Base* For cross-chain bridge, the destination chain must be different from the source chain. *** #### To Token Select the destination token to receive. Example: *WETH (Wrapped Ether)* *** #### Amount Enter the human-readable amount to bridge. Example: *0.1* Decimal automatically handles token decimals during execution. This field is required. *** #### Recipient (Optional) Specify a recipient wallet address for the bridge tokens. * If left empty, tokens are received in the connected wallet * Useful for routing funds to external wallets or contracts
Example: *0x...* *** ### Output & Execution When executed, the LayerZero node: * Fetches the optimal bridge route * Executes the bridge onchain * Returns execution details to the workflow Typical output includes: * Transaction hash * Source and destination tokens * Amounts bridged * Execution status These results can be used in downstream nodes for validation, logging, or follow-up actions. *** ### Example Workflow Use Case: Bridge ETH (Ethereum) to WETH (Base) automatically. Workflow: 1. Trigger 2. Wallet Connection 3. LayerZero Bridge 4. If Else (validate execution) 5. Transfer or store result This enables fully automated bridge workflows without manual intervention. *** **Here are the official 1inch references** * LayerZero Documentation:
Example: *0x...* *** ### Output & Execution When executed, the LayerZero node: * Fetches the optimal swap route * Executes the bridge onchain * Returns execution details to the workflow Typical output includes: * Transaction hash * Source and destination tokens * Amounts swapped * Execution status These results can be used in downstream nodes for validation, logging, or follow-up actions. *** ### Example Workflow Use Case: Swap ETH to WETH on BASE automatically. Workflow: 1. Trigger 2. Wallet Connection 3. LayerZero Swap 4. If Else (validate execution) 5. Transfer or store result This enables fully automated swap workflows without manual intervention. *** **Here are the official 1inch references** * LayerZero Documentation: [https://docs.layerzero.network/](https://docs.layerzero.network/v2/developers/value-transfer-api/api-reference/overview) * LayerZero Developer Docs (API & Protocol):[ https://portal.1inch.dev](https://portal.1inch.dev) * LayerZero on X (Twitter):[ https://x.com/1inch](https://x.com/1inch) # If Else ### Overview The If Else allows you to add conditional logic to a Decimal workflow. It evaluates a condition and determines whether the workflow should proceed based on the result. This node is used to: * Make decisions inside workflows * Branch logic based on data values * Validate API responses * Control execution flow dynamically If Else is a core control node and is commonly used after API calls, data transformations, or variable assignments. *** ### Available Module #### If Else Evaluates a comparison between two values and returns a boolean result that can be used to control downstream workflow execution. *** ### When to Use If Else Use If Else when: * You need to compare values (numbers or strings) * Workflow behavior depends on runtime data * You want to validate conditions before proceeding * You want to prevent invalid or unsafe actions
Typical use cases include: * Checking API response values * Comparing token prices or balances * Validating status codes * Enforcing thresholds or limits *** ### Adding If Else to a Workflow 1. Open the Decimal workflow editor 2. Add a Trigger or connect from an existing node 3. From Control, select If Else 4. Connect the node to the previous step in the workflow Once added, the If Else Settings panel opens automatically. *** ### Module Configuration #### Left Value Path The Left Value Path defines the value to evaluate from the current workflow context. * Uses dot or bracket notation * Refers to data produced by previous nodes
Example: *httpResult\[0].responseData.bitcoin.usd* This field is required.\ If empty or invalid, the node will not execute. *** #### Operator Select the comparison operator to apply. Supported operators include: * Equals (==) * Not Equals (!=) * Greater Than (>) * Less Than (<) * Greater Than or Equal To (>=) * Less Than or Equal To (<=)
Choose the operator based on the type of comparison required. *** #### Right Value The Right Value is the value to compare against. * Can be a number or a string * Must match the expected type of the left value Example: *113000* This field is required.  *** #### Result Variable Name Defines the variable name that will store the boolean result of the condition. Default example: *conditionResult* The result will be: * *true if the condition passes* * *false if the condition fails* This variable is available to all downstream nodes. *** ### Output & Variables After execution, the If Else node stores the result as a boolean variable. Example usage: *conditionResult === true* This result can be used to: * Control branching logic * Gate critical actions * Trigger follow-up steps conditionally
*** ### Example Workflow Use Case: Execute logic only when a condition is met. Workflow: 1. Trigger 2. Call API (fetch data) 3. If Else (validate condition) 4. Execute next step only if condition passes This allows workflows to behave dynamically based on real-time data. *** \ \
# Custom Code ### Overview The Custom Code node allows you to execute custom JavaScript logic inside a Decimal workflow. It is designed for scenarios where no-code nodes are not sufficient and custom data processing, transformation, or calculation is required. Custom Code acts as a lightweight compute layer within workflows and is commonly used to: * Transform API responses * Perform calculations * Format or normalise data * Apply custom business logic * Prepare data for downstream nodes This node bridges no-code automation with low-code flexibility. *** ### Available Module #### Custom Code The Custom Code node allows you to run user-defined custom Javascript codes and return processed results back to the workflow. Here you can define your own custom logic, processes, rules and strategies. It gives advanced control to users to manage their workflow states and build guardrails. *** ### When to Use Custom Code **Use Custom Code when:** * You need custom logic not supported by native nodes * Data needs transformation or aggregation * Calculations must be applied dynamically * Workflow behavior depends on computed values **Typical use cases include:** * Parsing API responses * Calculating thresholds or metrics * Restructuring objects or arrays * Validating or enriching data *** ### Adding Custom Code to a Workflow 1. Open the Decimal workflow editor 2. Add a Trigger or connect from an existing node 3. From Transform, select Custom Code 4. Connect the node to the previous step Once added, the Run Code Settings panel opens automatically. *** ### Module Configuration #### Mode The Mode determines how the code is executed. **Run Once for All Items** * Executes the code once for the entire workflow execution * Suitable for aggregation, calculations, or global transformations *(Additional modes may be introduced in future versions.)* *** #### JavaScript Code This field contains the JavaScript code to execute. * Click Open Editor to edit the full code in a popup * The code runs in the context of the current workflow item * Data from previous nodes is accessible within the execution context **Example:** *return {* *value: 100,* *status: "processed"* *};* The returned object becomes available to downstream nodes. *** ### Output & Variables The output of the Custom Code node is automatically passed forward in the workflow. Downstream nodes can access: * Computed values * Transformed objects * Derived fields Example usage: *runCodeResult.value* \ The exact variable structure depends on the returned object. *** ### Example Workflow Use Case: Transform API response data. Workflow: 1. Trigger 2. Call API 3. Run Code (process response) 4. If Else or Set Variable This pattern allows raw API data to be reshaped before further use.
# Set Variable ### Overview The Set Variable integration allows you to store values within a Decimal workflow so they can be reused by downstream nodes. It helps manage workflow state, simplify data handling, and improve readability. Common uses include storing API results, computed values, and control flags. *** ### Module #### Set Variable Assigns a value to a named variable and makes it available to subsequent workflow steps. *** ### When to Use Set Variable Use this node when you need to: * Store intermediate values * Reuse data across multiple nodes * Simplify complex data paths * Maintain workflow state *** ### Adding Set Variable to a Workflow 1. Open the Decimal workflow editor 2. Add or connect from an existing node 3. Select Transform → Set Variable 4. Connect it to the previous step The Set Variable Settings panel opens automatically. *** ### Configuration #### Variable Name Name of the variable to set. **Example**: *myVariable* Required field. *** #### Value Value to assign to the variable. **Example**: *100* Required field. *** #### Value Type Select the data type of the value: * String * Number * Boolean * JSON Choosing the correct type ensures proper usage downstream. *** ### Output The variable is stored in the workflow context and can be referenced by later nodes using its name. *** ### Example Use Case Use Case: Store a computed value for reuse. Workflow: 1. Trigger 2. Run Code (compute a value) 3. Set Variable (store the result) 4. Use the variable in later nodes
# Chain Connection The Chain Connection establishes a secure onchain execution context for a workflow. It defines which network, will be used to execute all subsequent Web3 actions. Every workflow that performs onchain operations—such as token transfers, swaps, or contract calls must begin with a Chain Connection node. ### Available Module #### Chain Connection Initialises a wallet session for the workflow and makes it available to downstream Web3 nodes. *** ### When to Use Chain Connection Use this node when your workflow: * Executes any onchain transaction * Signs messages or transactions * Transfers tokens or native assets * Interacts with smart contracts It should always be placed before other Web3 nodes. *** ### Adding Chain Connection to a Workflow 1. Open the Decimal workflow editor 2. Add a Trigger node 3. From Web3, select Chain Connection 4. Connect it directly after the trigger *** ### Module Configuration #### Wallet Type Defines the wallet execution model. This is default set to the sub-wallet. This is to ensure that the entire workflow is autonomous. Example: *Subwallet Auto* This automatically manages a subwallet for secure execution without exposing private keys. *** #### Network Select the blockchain network where all subseqent web3 transactions will be executed. Example: *Base* The selected network applies to all downstream Web3 actions unless overridden. *** ### Output & Execution Context Once configured, Wallet Connection: * Establishes a signing context * Binds the wallet to the workflow * Enables downstream nodes to execute transactions No explicit output variable is required—this node sets execution state. *** ### Example Workflow Use Case: Prepare a workflow for onchain execution. Workflow: 1. Trigger 2. Chain Connection 3. Transfer Funds / 1inch / Smart Contract Function *** # Sign Transaction (EIP-712) ### Overview The Sign transaction (EIP-712) allows you to generate typed data signatures using the EIP-712 standard directly within a Decimal workflow. It is commonly used for secure, structured message signing in Web3 applications, including authentication, off-chain approvals, and intent-based workflows. EIP-712 signatures are human-readable, deterministic, and widely supported across wallets and smart contracts. *** ### Available Module #### EIP-712 Sign Transaction Signs structured typed data using the connected wallet and returns the cryptographic signature for downstream use. *** ### When to Use EIP-712 Sign Transaction Use this node when your workflow needs to: * Sign structured data instead of raw messages * Generate off-chain approvals or authorizations * Support gasless or intent-based flows * Authenticate users or wallets securely * Interact with contracts that verify EIP-712 signatures This node must be used after Wallet Connection. *** ### Adding EIP-712 Sign to a Workflow 1. Open the Decimal workflow editor 2. Add a Trigger node 3. Add a Wallet Connection node 4. From Web3, select EIP-712 Sign 5. Connect it after the Wallet Connection The EIP-712 Sign Settings panel opens automatically. *** ### Module Configuration #### Domain Defines the signing domain for the typed data. Example: *{* *"name": "Example DApp",* *"version": "1",* *"chainId": 11155111,* *"verifyingContract": "0x0000000000000000000000000000000000000000"* *}* The domain ensures signatures are valid only within a specific application and chain context. *** #### Types Defines the schema of the typed data to be signed. Example: *{* *"EIP712Domain": \[* *{ "name": "name", "type": "string" },* *{ "name": "version", "type": "string" },* *{ "name": "chainId", "type": "uint256" },* *{ "name": "verifyingContract", "type": "address" }* *],* *"Mail": \[* *{ "name": "from", "type": "Person" },* *{ "name": "to", "type": "Person" },* *{ "name": "contents", "type": "string" }* *]* *}* This defines how the message data is structured and encoded. *** #### Primary Type Specifies the main type being signed. Example: *Mail* This must match one of the types defined in the Types configuration. *** #### Message The actual data payload to sign, matching the defined schema. Example: { "from": { "name": "Alice", "wallet": "0x6A036B3E4eb83FC8Bcf2351C266ea045117cA5DE" }, "contents": "Hello, Bob!" } This is the data that will be cryptographically signed. *** ### Output & Execution When executed, the EIP-712 Sign node: * Uses the connected wallet to sign the typed data * Produces an EIP-712 compliant signature * Makes the signature available to downstream nodes Typical outputs include: * Signature * Signer address * Typed data hash These outputs can be sent to APIs, stored, or verified onchain. *** ### Example Workflow Use Case: Generate an off-chain approval signature. Workflow: 1. Trigger 2. Wallet Connection 3. EIP-712 Sign 4. Call API / Smart Contract Function This enables workflows such as gasless approvals or delegated execution.
# Transfer Funds ### Overview The **Transfer Funds** node enables you to send native blockchain assets or supported tokens from a connected wallet to a specified recipient address. It is designed for both automated and manual workflows, allowing seamless value transfers within your automation logic. This node is commonly used for payouts, treasury operations, automated rewards, and operational fund movements. *** ### What Transfer Funds Does The Transfer Funds node executes an **on-chain transfer transaction** using the wallet connected earlier in the workflow. Key capabilities include: * Sending native tokens (e.g., ETH) * Sending supported ERC-20 tokens * Using dynamic values via variables * Executing transfers within automated or manual workflows *** ### Configuration Options #### 1. Recipient Address The blockchain address that will receive the funds. * Must be a valid Ethereum-compatible address * Supports static input or dynamic variables **Example:**\ `0x1234...abcd` *** #### 2. Amount The amount of funds to transfer. * Supports values in **ETH or wei**, depending on token type * Can be a fixed value or a variable * Decimal values are supported for native tokens **Example:**\ `0.001` *** #### 3. Token Type Select the asset you want to transfer. * **ETH** – Native Ethereum token * **ERC-20 Tokens** – Supported tokens available in the dropdown The available options depend on the connected network and wallet. *** #### 4. Variables Support You can use variables for: * Recipient address * Transfer amount * Token selection This enables dynamic transfers such as distributing rewards to multiple addresses or transferring amounts calculated earlier in the workflow. *** ### Common Use Cases * **Automated payouts and rewards** * **Treasury management operations** * **Recurring payments using Scheduler** * **Airdrop or incentive distribution** * **Testing fund transfers in development** *** ### Best Practices * Always verify the **recipient address** before execution. * Test transfers with **small amounts** using Manual Run. * Use **variables** for scalable and reusable workflows. * Ensure the connected wallet has sufficient balance and gas fees. * Combine with **Conditions & Branching** for safety checks. *** ### Example Workflow **Scenario:** Send 0.001 ETH to a user every time a workflow runs. 1. Trigger the workflow (Manual Run or Scheduler). 2. Connect a wallet. 3. Configure the **Transfer Funds** node: * Recipient Address: `0x...` * Amount: `0.001` * Token Type: `ETH` 4. Execute the workflow. Result: Funds are transferred on-chain to the specified address. # Read Smart Contract ### Overview The **Transfer Funds** node enables you to send native blockchain assets or supported tokens from a connected wallet to a specified recipient address. It is designed for both automated and manual workflows, allowing seamless value transfers within your automation logic. This node is commonly used for payouts, treasury operations, automated rewards, and operational fund movements. *** ### What Transfer Funds Does The Transfer Funds node executes an **on-chain transfer transaction** using the wallet connected earlier in the workflow. Key capabilities include: * Sending native tokens (e.g., ETH) * Sending supported ERC-20 tokens * Using dynamic values via variables * Executing transfers within automated or manual workflows *** ### Configuration Options #### 1. Recipient Address The blockchain address that will receive the funds. * Must be a valid Ethereum-compatible address * Supports static input or dynamic variables **Example:**\ `0x1234...abcd` *** #### 2. Amount The amount of funds to transfer. * Supports values in **ETH or wei**, depending on token type * Can be a fixed value or a variable * Decimal values are supported for native tokens **Example:**\ `0.001` *** #### 3. Token Type Select the asset you want to transfer. * **ETH** – Native Ethereum token * **ERC-20 Tokens** – Supported tokens available in the dropdown The available options depend on the connected network and wallet. *** #### 4. Variables Support You can use variables for: * Recipient address * Transfer amount * Token selection This enables dynamic transfers such as distributing rewards to multiple addresses or transferring amounts calculated earlier in the workflow. *** ### Common Use Cases * **Automated payouts and rewards** * **Treasury management operations** * **Recurring payments using Scheduler** * **Airdrop or incentive distribution** * **Testing fund transfers in development** *** ### Best Practices * Always verify the **recipient address** before execution. * Test transfers with **small amounts** using Manual Run. * Use **variables** for scalable and reusable workflows. * Ensure the connected wallet has sufficient balance and gas fees. * Combine with **Conditions & Branching** for safety checks. *** ### Example Workflow **Scenario:** Send 0.001 ETH to a user every time a workflow runs. 1. Trigger the workflow (Manual Run or Scheduler). 2. Connect a wallet. 3. Configure the **Transfer Funds** node: * Recipient Address: `0x...` * Amount: `0.001` * Token Type: `ETH` 4. Execute the workflow. Result: Funds are transferred on-chain to the specified address. # Write Smart Contract ### Overview The **Transfer Funds** node enables you to send native blockchain assets or supported tokens from a connected wallet to a specified recipient address. It is designed for both automated and manual workflows, allowing seamless value transfers within your automation logic. This node is commonly used for payouts, treasury operations, automated rewards, and operational fund movements. *** ### What Transfer Funds Does The Transfer Funds node executes an **on-chain transfer transaction** using the wallet connected earlier in the workflow. Key capabilities include: * Sending native tokens (e.g., ETH) * Sending supported ERC-20 tokens * Using dynamic values via variables * Executing transfers within automated or manual workflows *** ### Configuration Options #### 1. Recipient Address The blockchain address that will receive the funds. * Must be a valid Ethereum-compatible address * Supports static input or dynamic variables **Example:**\ `0x1234...abcd` *** #### 2. Amount The amount of funds to transfer. * Supports values in **ETH or wei**, depending on token type * Can be a fixed value or a variable * Decimal values are supported for native tokens **Example:**\ `0.001` *** #### 3. Token Type Select the asset you want to transfer. * **ETH** – Native Ethereum token * **ERC-20 Tokens** – Supported tokens available in the dropdown The available options depend on the connected network and wallet. *** #### 4. Variables Support You can use variables for: * Recipient address * Transfer amount * Token selection This enables dynamic transfers such as distributing rewards to multiple addresses or transferring amounts calculated earlier in the workflow. *** ### Common Use Cases * **Automated payouts and rewards** * **Treasury management operations** * **Recurring payments using Scheduler** * **Airdrop or incentive distribution** * **Testing fund transfers in development** *** ### Best Practices * Always verify the **recipient address** before execution. * Test transfers with **small amounts** using Manual Run. * Use **variables** for scalable and reusable workflows. * Ensure the connected wallet has sufficient balance and gas fees. * Combine with **Conditions & Branching** for safety checks. *** ### Example Workflow **Scenario:** Send 0.001 ETH to a user every time a workflow runs. 1. Trigger the workflow (Manual Run or Scheduler). 2. Connect a wallet. 3. Configure the **Transfer Funds** node: * Recipient Address: `0x...` * Amount: `0.001` * Token Type: `ETH` 4. Execute the workflow. Result: Funds are transferred on-chain to the specified address. # Security Decimal is built with security-first principles. We know that your workflows touch critical systems - from financial transactions to community data - so protecting your automations, data, and keys is our top priority. ### 1. Core Security Principles * Zero-Trust Architecture – every request is verified, and no implicit trust is given to nodes, connectors, or users. * End-to-End Encryption – all data in transit uses TLS 1.2+ and sensitive data at rest is encrypted with AES-256. ### 2. Data Protection * Secrets Vault – all API keys, and user credentials are stored in an isolated, encrypted TEE vault, never in plaintext. * No Silent Data Capture – Decimal does not log or store workflow payloads beyond the immediate execution. All logs are available on the browser, and get deleted immediately after execution. * User Ownership – you can revoke integrations or delete all data at any time. ### 3. Wallet & Web3 Security * Non-Custodial by Default – Decimal does not hold or control your funds. * Decimal wallet is powered by [CDP](https://www.coinbase.com/en-in/developer-platform/products/wallets), secured inside a TEE and tightly tied in with the User's wallet. * Secure Signing – all on-chain transactions use secure signing mechanisms (e.g., WalletConnect, hardware wallets, or API keys provided by you). * Audit Trails – every blockchain interaction triggered by a workflow is logged for transparency. ### 4. Infrastructure Security * Containerized Execution – workflows run in isolated TEE environments, reducing risk of cross-contamination. * Marlin TEEs (Oysters) provide computation guarantee and proofs to ensure executions are exactly as per the instructions set by the user. * Rate Limiting & Throttling – prevents abuse and DDOS attacks ensures high reliability of shared resources. * Regular Audits – all components and connectors undergo periodic code audits and penetration tests. ### 5. Compliance & Standards * SOC 2 (in progress) – following best practices for security, availability, and confidentiality. * GDPR / Data Privacy – our entire system is designed to safeguard user's privacy and anonymity, so no user data is ever stored on our system. * Best Practices for Web3 – Only verified smart contracts and on-chain modules are onboarded onto the platform. ### 6. Shared Responsibility Decimal provides the infrastructure and guarantees secure execution, but security is a shared responsibility: * Always use strong authentication for your accounts. * Rotate API keys regularly. * Use only trusted Web3 vendors and third-party connectors. ### 7. Why This Matters Security isn’t just about avoiding losses; it’s about trusting your automations to run without worry. With Decimal: * You don’t risk losing keys or sensitive data to a silo platform. * You retain control over your wallets and workflows. * You gain the peace of mind that every execution is isolated, auditable, and protected. # Bespoke Oracles Your data, your way. ### What are Oracles? In the context of blockchain, oracles act as bridges between smart contracts and external data sources. Smart contracts, which are contracts with the terms of the agreement directly written into code, often require real-world data to trigger and execute certain conditions. Oracles facilitate this interaction by securely fetching and providing external data to the blockchain. ### Approches for Oracles Oracles today have this inherent trade off between decentralization, cost and speed. Oracles which are centralized are fast and cheap and the ones who are decentralized are slow and inefficient. There have been attempts to solve this problem and the solutions lie on this spectrum of centralized to decentralized by making the above tradeoffs. ### Ideal Oracle Ideally an oracle should be able to provide information with the following characteristics * secure (results from oracle are provable onchain) * cost efficient (oracle data is calculated only once for max efficiency) * Frequency (oracle can update data in sub milli second intervals) * Permissionless * For agents (agents who feed data to oracles should be able to join without any whitelisting) * For oracle feed (oracle should be able to execute arbitrary logic before submitting the feed) * For users (any user should be able to join and specific requests) We will explore various approaches to oracles and how close are they to the ideal oracle in ecosystem-comparision page. ### Decimal's approach The purpose of Decimal is to make data available for all – in a **reliable, accurate and fast manner**. * The data should be beyond reproach, always verifiable and auditable. * The system should be sustainable, involving efficient practices to incur minimal wastage and costs for the users and the environment. * Everyone is unique, and so are their data requirements. Hence, the oracles providing these data should also be equally customizable. * The data should be accessible for all – with minimal onboarding overheads. *** [In short – your data, exactly how you want it, when you want it.](#user-content-fn-1)[^1] [^1]: # Liquidation ### Client Lending and Borrowing protocols ### Monitoring (optional) + Liquidation 1. **Liquidation only:** Most clients with an existing integration with an oracle, self-monitor the health factors of their assets. If a certain threshold is reached, they send an Liquidation Intent trigger to Decimal to automatically fulfil the task of their assets liquidation and paying back their lenders per the best available market rate. 2. **Monitoring + Liquidation:** In some cases, the newer protocols have requested Decimal to also undertake responsibility of monitoring multiple oracles with predefined health factor triggers. Decimal solvers undertake the task of both monitoring the assets and automatically trigger the liquidation task when the right conditions are identified. This saves the clients significant cost and effort of integration and monitoring oracle prices while having the flexibility to dynamically switch service providers of their choice to maximise their gains. *** [In short – focus on your core work.](#user-content-fn-1)[^1] [^1]: # Yield Aggregation Cross-chain Yields ### Client Investment portfolio mangers and companies. ### Investment strategies Clients define different investment strategies that span across different chains, protocols, AVSs etc. Each strategy yields rewards in their respective tokens and becomes increasingly difficult to keep track of. ### Yield Monitoring and Withdrawals Decimal is employed to track these different yields in respective tokens. Once the yields hit a set target, solvers automatically withdraw and bridge the respective tokens, consolidate them and pay back the clients. This offers clients greater flexibility towards more sophisticated fund allocations without the hassles of the associated complex cross-chain aggregation process. *** [In short – cross-chain yields made easy.](#user-content-fn-1)[^1] [^1]: # Swaps Any-to-Any token ### Swap Convert any token into another token # Bridges Your chain, your way. ### Cross-chain Having access to liquidity and tokens across chains. # Portfolio Rebalance Your data, your way. ### What are Oracles? In the context of blockchain, oracles act as bridges between smart contracts and external data sources. Smart contracts, which are contracts with the terms of the agreement directly written into code, often require real-world data to trigger and execute certain conditions. Oracles facilitate this interaction by securely fetching and providing external data to the blockchain. ### Approches for Oracles Oracles today have this inherent trade off between decentralization, cost and speed. Oracles which are centralized are fast and cheap and the ones who are decentralized are slow and inefficient. There have been attempts to solve this problem and the solutions lie on this spectrum of centralized to decentralized by making the above tradeoffs. ### Ideal Oracle Ideally an oracle should be able to provide information with the following characteristics * secure (results from oracle are provable onchain) * cost efficient (oracle data is calculated only once for max efficiency) * Frequency (oracle can update data in sub milli second intervals) * Permissionless * For agents (agents who feed data to oracles should be able to join without any whitelisting) * For oracle feed (oracle should be able to execute arbitrary logic before submitting the feed) * For users (any user should be able to join and specific requests) We will explore various approaches to oracles and how close are they to the ideal oracle in ecosystem-comparision page. ### Decimal's approach The purpose of Decimal is to make data available for all – in a **reliable, accurate and fast manner**. * The data should be beyond reproach, always verifiable and auditable. * The system should be sustainable, involving efficient practices to incur minimal wastage and costs for the users and the environment. * Everyone is unique, and so are their data requirements. Hence, the oracles providing these data should also be equally customizable. * The data should be accessible for all – with minimal onboarding overheads. *** [In short – your data, exactly how you want it, when you want it.](#user-content-fn-1)[^1] [^1]: # Community & Support * Follow us on Twitter * Join the Discord/Telegram * Submit Feature Requests * Report Bugs *** ### Where to Connect * **Discord** – Technical support, community discussions, and showcases, Share ideas, feature requests, and bug reports. * **Telegram** – Real-time chat with the Decimal team and other builders. * **Twitter** – Follow updates, announcements, and product releases. ### 2. Support Channels * Documentation First – Our GitBook is designed to help you solve most issues directly. * Community Support – Ask and answer questions in Discord/Telegram. * Email Support – Reach us at \[