Security Model

Sign-In With Ethereum (SIWE)

FlowNodes uses EIP-4361 Sign-In With Ethereumfor authentication. This is a standardised, audited protocol for Ethereum-based login.

How it works

1. 1

   Browser requests a nonce

   The FlowNodes API generates a cryptographically random nonce (UUIDv4) and returns it. The nonce is stored server-side with a 5-minute expiry.

2. 2

   Wallet signs the message

   The SIWE message includes: domain (flownodes.xyz), address, nonce, issuedAt, and a human-readable statement. Your wallet signs this with your private key (no gas, no transaction).

3. 3

   Server verifies the signature

   The API recovers the signer address from the EIP-712 signature and checks it matches the claimed address. The nonce is consumed (one-time use).

4. 4

   Session cookie issued

   A short-lived encrypted session cookie (iron-session, AES-256-CBC) is set. Default duration: 24 hours. The cookie is HttpOnly and Secure.

What FlowNodes never sees

• ✗Your private key — ever, under any circumstances
• ✗Your seed phrase or keystore file
• ✗Your wallet balance or transaction history
• ✗Any other accounts in your wallet

What FlowNodes does store

• ✓Your Ethereum address (public — it's on-chain)
• ✓Your ENS name (resolved at login, cached)
• ✓Your FlowNodes username (if you set one)
• ✓Your project canvas graphs (your IP — deletable on request)
• ✓Your credit ledger entries (required for billing accuracy)

Non-custodial design

FlowNodes never holds your ETH or tokens.Here's how each financial interaction works:

Paying for credits (ETH deposit)

When you top up credits, you call FlowNodesPaymentVault.deposit(bytes32 userId)directly from your wallet. Your ETH goes into the vault contract. The vault is owned by FlowNodes but is fully auditable on Etherscan. FlowNodes cannot rug the vault — there are no withdrawal functions accessible to non-owners except refunds.

Deploying contracts

When you deploy a contract, your wallet signs and broadcasts the deployment transaction. FlowNodes constructs the transaction data (encoded bytecode + constructor args) but never has access to sign it. The gas comes from your wallet. The contract is owned by your address.

Source code and AI prompts

Your Solidity source code and AI prompts are sent to our servers for processing (security scans run via E2B; AI generation uses Anthropic). This data is not shared with third parties beyond what is necessary to fulfil the service. E2B sandboxes are destroyed immediately after each scan. Anthropic processes prompts according to their data processing agreement.

Credit system architecture

Credits are an accounting abstraction over ETH. Here's the full lifecycle:

Deposit flow

1. 1User calls vault.deposit(userId) with ETH amount
2. 2Vault emits Deposited(userId, amount, txHash) event
3. 3Alchemy webhook fires and calls /api/webhooks/alchemy
4. 4API waits for 12 block confirmations
5. 5Chainlink ETH/USD price is queried at the confirmed block
6. 6credits = floor(ethAmount * ethUsdPrice * 100) added to user balance
7. 7CreditLedger row inserted: direction=CREDIT, referenceType=DEPOSIT

Credit deduction

Credits are deducted atomically in database transactions before each paid operation. If the operation fails (AI error, scan timeout, deploy revert), credits are automatically refunded to your balance via a CREDIT ledger entry.

Credit balance integrity

The creditsBalance on the user record is updated atomically with each ledger entry using a database transaction. The ledger is append-only and provides a full audit trail. You can view your complete transaction history on the Credits page.

FlowNodesPaymentVault contract

The payment vault is a custom Solidity contract deployed on Ethereum Mainnet. It is verified on Etherscan. Key properties: