A visual, node-based editor for Avalanche smart contracts, split into two deliberately separate surfaces:

• The canvas is a deterministic visual programming tool. Contract, Variable, Struct, Mapping, Function, Modifier, and Event nodes compile straight to Solidity via a pure, non-AI compiler (src/lib/compiler.ts). Nothing on the canvas calls an LLM.
• The AI Assistant is a persistent chat panel next to the canvas. It's a copilot, not a node — you describe what you want, it proposes a batch of node/edge operations, and those get dropped onto the canvas for you to keep editing by hand.

• Next.js 15 (App Router, TypeScript)
• React Flow for the node canvas
• Zustand for canvas state (nodes/edges + the op-application bridge for the assistant) and wallet state
• viem for wallet connection (injected provider) and the deploy transaction — no wagmi/RainbowKit
• solc (real compiler, server-side) + @openzeppelin/contracts for import resolution — actual bytecode, not a stub
• Claude (Anthropic API), used in exactly two places: the Assistant panel (via tool-calling) and the Audit action in the Code tab — never embedded in a canvas node
• Tailwind CSS v4 for styling

┌────────────┬─────────────────────────────────────┬──────────────────┐
│  Palette   │  Canvas  |  Code  ← tabs              │  AI Assistant    │
│  (drag     │                                        │  (chat, calls    │
│  nodes in) │  Canvas tab: React Flow graph          │  /api/assistant, │
│            │  (Contract/Variable/Struct/Mapping/    │  proposes ops)   │
│            │  Function/Modifier/Event/Note nodes)   │                  │
│            │  — no AI calls here                    │                  │
│            │                                        │                  │
│            │  Code tab: full syntax-highlighted     │                  │
│            │  compiled Solidity, + Audit /           │                  │
│            │  Deploy-preview sub-tabs                │                  │
└────────────┴─────────────────────────────────────┴──────────────────┘

• A Contract node is the root. Connect any other node type to it (contract -> node edge) to make it a member.
• Connect a Modifier node's output into a Function node's input (modifier -> function edge) to apply that modifier to the function.
• src/lib/compiler.ts walks the graph and emits real Solidity — imports for a few common OpenZeppelin parents (ERC20, Ownable, AccessControl, ReentrancyGuard, Pausable, …), structs, events, state variables, modifiers, and functions/constructor in order.

• src/app/api/assistant/route.ts sends the chat history plus a summary of the current graph to Claude with a propose_canvas_changes tool.
• Claude replies with normal chat text, and — only when asked to build or change something — a batch of ops: add_node, add_edge, update_node, remove_node.
• useFlowStore.applyAssistantOps (in src/lib/flow-store.ts) resolves temporary ids to real node ids, auto-lays-out new nodes near their parent, and applies the batch to the canvas.
• The assistant never emits raw Solidity as its answer — it always speaks in nodes, so anything it "writes" is inspectable and editable on the canvas afterward.

• Connect Wallet (top bar) connects an injected browser wallet (MetaMask, Core, etc. — anything exposing window.ethereum) via a thin viem-based store (src/lib/wallet-store.ts), no wagmi/RainbowKit needed. Shows a network badge and offers to switch/add Avalanche Fuji if you're on the wrong chain.
• The Deploy sub-tab (in the Code tab) is a real three-step flow:
  1. Compile — /api/compile runs the actual solc compiler (Node.js, server-side) against the graph's compiled Solidity, resolving @openzeppelin/* imports straight from node_modules. Returns a real ABI and bytecode — this isn't illustrative.
  2. Constructor arguments — a form generated from the compiled ABI's constructor inputs (plus a value field if it's payable).
  3. Deploy — signs and sends the deployment transaction from your connected wallet via walletClient.deployContract, waits for the receipt, and links the tx and the new contract address on Snowtrace (Fuji).
• Real deploy is Fuji-only by design — there's no mainnet deploy button, only the mainnet option in the Hardhat script preview (still available via "Show Hardhat deploy script instead" further down the same tab) for anyone who wants to deploy via their own tooling.

• Run audit — sends the compiled Solidity to Claude for a scored security + gas review (/api/audit).

Save to ZIP (Code tab → Compiled code, next to Copy) downloads a complete, ready-to-run Hardhat project — not just the .sol file: contracts/{Name}.sol, scripts/deploy.ts, hardhat.config.ts (Fuji + mainnet networks pre-wired, Solidity version auto-matched to your contract's pragma), package.json, .env.example, .gitignore, and a README.md. If the constructor takes arguments, the README calls that out explicitly so it's not a silent deploy failure. Built client-side with jszip — no server round-trip.

npm install
cp .env.local.example .env.local
# then edit .env.local and set ANTHROPIC_API_KEY
npm run dev

Open http://localhost:3000. Pick a Template (top-right dropdown, or the empty-canvas grid) for a ready-made contract, or drag nodes in from the left panel and connect them yourself. Try asking the Assistant something like "add a withdraw function with a reentrancy guard modifier".

src/lib/templates.ts ships six ready-made graphs, each a fully wired node set you can load, inspect, and keep editing:

All six compile cleanly (verified against the compiler directly, not just visually) and demonstrate the two fields that make inheritance actually work: a contract's baseConstructorCalls (for parent constructors like ERC20("Name","SYM")) and a function's extraModifiers (for inherited modifiers like onlyOwner that don't need their own Modifier node).

• POST /api/assistant — { messages, graph } → { reply, ops }. The only route that can add/change canvas nodes, and only because the user asked in chat.
• POST /api/audit — { code } → { score, summary, findings, gasFindings }
• POST /api/compile — { code, contractName } → { abi, bytecode, warnings }, real solc compilation
• POST /api/deploy-preview — { code, contractName, network, constructorArgs? } → { deployScript, abiPreview, notes } (Hardhat script text, no compilation)

• No wallet-agnostic connect UI. Wallet connection uses the raw injected-provider API (window.ethereum) directly — works with MetaMask, Core, and most browser wallets, but there's no WalletConnect / mobile-wallet support and no multi-wallet picker.
• No mainnet deploy. Real signed deployment is Fuji-only by design; mainnet is preview-script-only.
• No persistence. Flows and chat history live in memory and reset on reload; deployed-contract history isn't saved anywhere either.
• Single contract per canvas. The compiler takes the first Contract node it finds; multi-contract graphs (and cross-contract calls) aren't supported yet.
• No struct-typed function params. The compiler auto-adds memory for string/bytes/array parameter types, but doesn't know your custom struct names, so a struct-typed parameter needs memory added by hand in its type field (e.g. Proposal memory).

This section should list any major frameworks/libraries used to bootstrap your project. Leave any add-ons/plugins for the acknowledgements section. Here are a few examples.

(back to top)

This is an example of how you may give instructions on setting up your project locally. To get a local copy up and running follow these simple example steps.

This is an example of how to list things you need to use the software and how to install them.

• npm

  npm install npm@latest -g

Below is an example of how you can instruct your audience on installing and setting up your app. This template doesn't rely on any external dependencies or services.

1. Get a free API Key at https://example.com
2. Clone the repo

   git clone https://github.com/github_username/repo_name.git

3. Install NPM packages

   npm install

4. Enter your API in config.js

   const API_KEY = 'ENTER YOUR API';

5. Change git remote url to avoid accidental pushes to base project

   git remote set-url origin github_username/repo_name
   git remote -v # confirm the changes

(back to top)

Use this space to show useful examples of how a project can be used. Additional screenshots, code examples and demos work well in this space. You may also link to more resources.

For more examples, please refer to the Documentation

(back to top)

• Add ORganisiontal Github
• Add back to top links
• Add Additional Templates w/ Examples
• Add "components" document to easily copy & paste sections of the readme
• Multi-language Support
  • Chinese
  • Spanish

See the open issues for a full list of proposed features (and known issues).

(back to top)

Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!

1. Fork the Project
2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
3. Commit your Changes (git commit -m 'Add some AmazingFeature')
4. Push to the Branch (git push origin feature/AmazingFeature)
5. Open a Pull Request

(back to top)

Distributed under the Unlicense License. See LICENSE.txt for more information.

(back to top)

Your Name - @your_twitter - email@example.com

Project Link: https://github.com/your_username/repo_name

(back to top)

Use this space to list resources you find helpful and would like to give credit to. I've included a few of my favorites to kick things off!

• Choose an Open Source License
• GitHub Emoji Cheat Sheet
• Malven's Flexbox Cheatsheet
• Malven's Grid Cheatsheet
• Img Shields
• GitHub Pages
• Font Awesome
• React Icons

(back to top)