Visual Builder Learning Path
A complete path for learning the visual editor: what each node does, when to use it, how connections work, then two guided program builds.
Learn each node before building
The visual builder becomes easier when each node has one job in your head. Read these as the mental model for the editor.
The root of the program. Use one Program node per visual builder project.
Fields: name, version, programId, description
Connects: Program -> Instruction
Avoid: Do not connect Program directly to Account, State, or Logic.
A callable entry point like initialize, deposit, withdraw, create_escrow, or accept_trade.
Fields: name, args, accessControl
Connects: Program -> Instruction, Instruction -> Account, Instruction -> Logic
Avoid: Do not put account data fields here. Put stored data in State nodes.
A Solana account passed into an instruction. It can be signer, mutable, init, token account, mint, PDA, or unchecked.
Fields: name, accountType, flags, seeds, payer, space
Connects: Instruction -> Account, State -> Account, Account -> Constraint
Avoid: Do not use Account as the stored data schema. Use State for that.
The stored struct for program-owned account data.
Fields: name, fields, derives
Connects: State -> Account
Avoid: State does not connect to Program or Instruction directly.
A validation rule attached to an account: seeds, owner, has_one, address, mint, token authority, close target.
Fields: constraintType, account, expression, seeds
Connects: Account -> Constraint
Avoid: Do not attach a constraint to the instruction. Attach it to the account being checked.
The instruction body: require checks, transfers, minting, burning, math, CPI, if/else, custom code.
Fields: logicType, inputs, outputs, order
Connects: Instruction -> Logic, Logic -> Logic
Avoid: Do not connect Logic directly to Program. Logic runs inside an Instruction.
A structured event that an instruction can emit for clients and indexers.
Fields: name, fields
Connects: Instruction -> Event
Avoid: An Event describes output. It is not an executable step by itself.
A custom error variant used by require checks or return-error logic.
Fields: name, code, message
Connects: Instruction -> Error
Avoid: Errors are referenced by logic; they are not accounts.
Learn the connection grammar
Connections describe ownership, inputs, validation, and execution. If a connection fails in the editor, check this grammar first.
Program -> Instruction
The program exposes this callable handler.
Instruction -> Account
The handler receives this Solana account.
State -> Account
This account stores this data struct.
Account -> Constraint
This account must satisfy this validation rule.
Instruction -> Logic
This operation runs inside the handler.
Logic -> Logic
These operations run in sequence.
Instruction -> Event
This handler may emit this event.
Instruction -> Error
This handler may return this custom error.
Guided build: Vault
Build this first. It teaches the normal Solana shape: one program, multiple instructions, one state-backed account, one validation rule, and one transfer operation.
Build order
Add Program, add initialize, add deposit, add vault account, bind Vault state, add has_one authority, add transfer_sol logic, then run the connection check below.
Guided build: Escrow
Escrow is the next level because state persists between instructions and token accounts participate in the trade.
Build order
Add initialize_escrow and accept_trade, create Escrow state, connect escrow/token accounts to initialize, connect escrow and transfer_token logic to accept_trade, then attach close behavior to the escrow account.
What you should be able to build next
After Vault and Escrow, most beginner Solana programs are variations of the same shape.
Counter
Program -> increment instruction -> counter account -> Counter state -> math logic
Token gate
Instruction -> wallet account -> token account -> require balance logic
Simple DAO
Program -> create_proposal/vote -> Proposal state -> voter account -> require and math logic