FlowForge

Flow Forge is a visual workflow platform for DeFi that lets users sign in with email (via Privy), create and run multi-step workflows with drag-and-drop nodes, and interact with an AI agent on Telegram - all without dealing with wallet setup or repeated transaction approvals for each step.

Users get:

• No-wallet hassle: Sign in with email; Flow Forge creates and manages a Safe smart contract wallet for them on Arbitrum One. The user is the sole owner; Flow Forge acts as a trusted executor for programmatic execution.
• Visual workflows: Build DeFi workflows from a wide set of tools—oracle swaps, bridges, lending, perpetuals, notifications—using templates or other users’ public workflows.
• Telegram agent: A natural-language layer that turns prompts into workflows and runs them. Users don’t have to design the graph; the agent handles workflow design and constraints in plain language.
• Controlled autonomy: A user spending policy (per-transaction limit, daily limit, deadline) is set once via a single signed Safe transaction. The agent can then execute within those limits without asking for approval on every tx.
• Reliability via CRE: Executions use Chainlink CRE for deterministic, consensus-backed runs. Multiple nodes agree on the result, so the user gets a single verified outcome instead of trusting a single backend.
• An array of tools and protocols at their hands: bridge (LiFi), swap (Uniswap), price oracle (ChainLink, Pyth), perpetuals trading (Ostium), lending (Aave, Compound), prediction markets (PolyMarket), social connections (Slack, Telegram, Email), control nodes (If/Else, Switch, Timers) and many more to come.

The project started as a visual workflow builder with email login and Safe wallets; then added the Telegram agent (with per-tx approval); and now runs with CRE-backed execution and the spending-policy hook so the agent can run freely within user-defined limits.

Frontend (Next.js, React, Privy)

• Next.js 16, React 19, React Flow for the canvas.
• Privy for email/wallet auth; users connect a wallet once, and the app uses that address as the Safe owner.
• Onboarding: create/link Safe, connect Telegram (verification code + bot), set spending policy (limits + deadline, one Safe tx).

Backend (Node/Express, PostgreSQL, Redis, BullMQ)

• TypeScript/Express API. Workflows are JSON DAGs (nodes + edges); the engine runs the right node processor per step.
• Safe lifecycle: relay endpoints create Safe via FlowForgeSafeFactory, enable FlowForgeSafeModule, and (via spending-policy controller) prepare/execute the policy Safe tx that calls FlowForgeSpendingPolicy.setPolicy.
• Execution: ExecutionService checks spending policy (DB + on-chain hook), then NodeProcessor executes the action.
• Spending policy: DB tables for policies and ledger; SpendingPolicyService checks allowance and records spends; controller serves GET/upsert/prepare/execute for the policy contract.
• Telegram: Webhook + controllers for linking chats (verification codes), and agent routes for context and execution.

Contracts (Solidity, Foundry)

• FlowForgeSafeFactory: Creates Safe proxies (SafeProxyFactory + singleton) for a given user.
• FlowForgeSafeModule: Only the configured executor can call execTask(safeAddress, to, value, data, operation, declaredUsdValue). Has IExecutioHook as a hook.
• FlowForgeSpendingPolicy: Implements IExecutionHook. Each Safe has a policy (deadline, active, spendLimitPerTx, dailyLimitUsd, 8-decimal USD). beforeExecution reverts if inactive, expired, or over limits; afterExecution updates dailySpent.

Agent (Telegram + uniform API)

• Node service: Telegram bot with pre-defined templates and prompt-to-workflow design capabilities.
• Converts natural language to workflow steps; calls backend to run executions; uses backend for user/agent context (Privy + Telegram link).
• Executions go through CRE + spending policy, so the user sees results in Telegram without extra sign-in steps when within limits.

CRE integration (hackathon/demo)

• Local CRE: Backend uses the cre CLI in “simulate” mode:
  cre workflow simulate ./workflow --target staging-settings --non-interactive [--broadcast] --trigger-index 1 --http-payload @payload.json
• Workflows:
  • Oracle: simulateOracleCli — reads Chainlink price feeds; used for oracle nodes.
  • LI.FI swap: simulateLifiQuoteCli for quote; executeLifiSwapCli for execution. The workflow’s main.ts fetches LI.FI quote (with CRE HTTP capability), builds the Safe module execTask calldata (safeAddress, target, value, data, operation, declaredUsdValue), and sends the tx from the executor key (from CRE secrets).
  • Ostium (perpetuals trading) and PolyMarket (prediction market) are works in progress.
• Backend writes per-execution payload/result JSON under each workflow’s workflow/ dir; the CLI runner parses “Workflow Simulation Result” from stdout and returns structured results to the node processors.
• With deploy access, the same workflows can be deployed to CRE for full consensus and broadcast.