The deploy gap: what Block's App Kit teaches Solana builders

Block's engineering team published something that will resonate with anyone who has shipped internal Solana tooling: the deploy gap. Building is no longer the bottleneck — AI handles scaffolding in minutes. The bottleneck is now "is there a safe place for the right people to use this?"

Block built App Kit to close that gap internally: SSO, secret management, data access controls, and an MCP-backed CLI — all baked in, no configuration required. Since March 2026 it has served 1,000+ distinct apps to thousands of users across 50+ departments, 80% of whom are non-engineers. The security org endorsed it as the official deployment method.

For Solana teams, the same gap shows up constantly. Someone builds a treasury dashboard over a weekend. It works on localhost. Then the CFO wants to use it. Then the validator team wants their own view. Then someone asks why it's reading from a hot wallet. The build took two hours; closing the deploy gap takes weeks — or never happens, and the tool dies on someone's laptop.

The Solana-specific version of the deploy gap

Generic app deployment is hard. Solana app deployment has extra surface area because the secrets are catastrophic if leaked:

• RPC API keys — Helius, QuickNode, Triton keys embedded in frontend bundles get scraped and rate-limited within hours. The fix (a server-side proxy) is five minutes of work that almost no one does until they get a bill.
• Program deploy keypairs — the keypair that can upgrade your program is the most sensitive secret in your stack. It belongs in a hardware wallet or a secrets manager, never in a.env file committed to a repo.
• Hot wallet private keys — scripts that automate on-chain operations (cranks, rebalancers, keepers) need a funded signing keypair. Where that keypair lives and who can read it is a security decision most teams defer indefinitely.
• Cross-environment RPC endpoints — devnet, testnet, mainnet — with different API keys per environment. A misconfigured environment variable that points mainnet tooling at devnet (or vice versa) is a class of bug that costs real money.

Lesson 1: separate building from deploying, by design

Block's core architectural insight: let the agent generate the application code, but have the platform own safety, durability, and infrastructure. The agent doesn't configure auth. The agent doesn't touch secrets. The agent writes business logic; the platform wraps it in the invariants the organisation requires.

Applied to Solana tooling, this means your internal tools should never embed credentials in application code. The application calls an interface; the platform resolves the credential at runtime from a secrets store it controls. The developer doesn't need to know where the RPC key lives — only that it exists and is valid for the environment.

// Bad — credential in application code (common in AI-generated Solana tools)
const connection = new Connection(
  "https://mainnet.helius-rpc.com/?api-key=abc123",
  "confirmed"
);

// Better — resolved from environment, never in source
const connection = new Connection(
  process.env.SOLANA_RPC_URL!,
  "confirmed"
);

// Best — resolved server-side, never exposed to the client at all
// api/rpc-proxy.ts
export async function POST(req: Request) {
  const body = await req.json();
  const res = await fetch(process.env.SOLANA_RPC_URL!, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  return new Response(await res.text(), { headers: { "Content-Type": "application/json" } });
}

The RPC proxy pattern is the most commonly skipped step in AI-generated Solana frontends. The model generates a working app. The app ships to production with the key in the bundle. The key gets scraped. Block's framework would have made this impossible at the platform level — the credential isn't available to the app at build time.

Lesson 2: deliberate constraints beat optional configuration

Block explicitly chose to limit flexibility: "The platform intentionally limits what teams can configure in order to guarantee consistent security properties." They found that offering choice created friction; removing choice created safety.

For Solana developer platforms, the analogy is opinionated tooling. The Solana Foundation's sol.new builder applies this — a constrained scaffold that bakes in wallet adapter, correct RPC configuration, and TypeScript types rather than leaving them as user decisions. The fewer decisions a developer makes about infrastructure, the fewer infrastructure mistakes they make.

A minimal opinionated Solana app scaffold looks like this:

# Opinionated scaffold — infrastructure decisions made, not offered
npx create-solana-app my-tool

# What it bakes in (non-negotiable):
# ✓ RPC via server-side proxy (SOLANA_RPC_URL never sent to client)
# ✓ Wallet adapter with WalletModalProvider
# ✓ Environment-aware cluster selection (devnet/mainnet by NODE_ENV)
# ✓ Sign In With Solana for auth (no password DB)
# ✓ Program IDL loaded from published address, not bundled
# ✓ .env.example with all required vars, .env in .gitignore

Lesson 3: auth needs to be the first dependency, not an afterthought

Block's three inadequate solutions for internal app deployment map cleanly onto the Solana ecosystem:

• Public hosting — deploys to Vercel, no auth, anyone with the URL can use it. Fine for a demo; a liability for anything touching real funds or internal data.
• General-purpose platforms — Retool, internal dashboards hosted on shared infra. Functional, but data leaves your control; not appropriate for wallet balances, order flow, or validator keys.
• Local scripts — the default for most Solana tooling. Only works for the person who wrote it. Doesn't scale to a team.

The Solana-native auth pattern that sidesteps all three problems is Sign In With Solana. The user signs a structured message with their wallet — no password database, no OAuth credentials to manage, and the signing key is something the user already controls. Pair it with a JWT and you have session-based access control that's native to the ecosystem.

import { SiweMessage } from "@solana/siws";
import { sign } from "tweetnacl";
import { PublicKey } from "@solana/web3.js";
import bs58 from "bs58";

// Server-side: verify a SIWS signature and issue a JWT
export async function verifySiws(message: string, signature: string, publicKey: string) {
  const siws = new SiweMessage(message);

  // Verify the message is well-formed and not expired
  await siws.verify({ nonce: siws.nonce });

  // Verify the Ed25519 signature
  const msgBytes = new TextEncoder().encode(message);
  const sigBytes = bs58.decode(signature);
  const pubKeyBytes = new PublicKey(publicKey).toBytes();

  const valid = sign.detached.verify(msgBytes, sigBytes, pubKeyBytes);
  if (!valid) throw new Error("Invalid signature");

  // Issue a JWT scoped to the wallet
  return issueJwt({ wallet: publicKey, role: await getWalletRole(publicKey) });
}

// getWalletRole — check an allowlist, a multisig, an NFT, an on-chain account
// This is where you implement "who is allowed to use this tool"
async function getWalletRole(wallet: string): Promise<string> {
  const ADMIN_WALLETS = new Set(process.env.ADMIN_WALLETS!.split(","));
  if (ADMIN_WALLETS.has(wallet)) return "admin";
  return "viewer";
}

Lesson 4: "quietly wrong" is worse than broken

Block's most important finding from their pilot: a measurement dashboard that looked polished but had subtle data-sampling errors was more dangerous than a dashboard that didn't exist. Teams made decisions from wrong numbers. Their fix: integration with authoritative data sources and test scaffolding in default templates.

The Solana equivalent is tools that silently read stale data. RPC nodes lag. Cached account data is seconds behind. A treasury dashboard that shows yesterday's token prices, or a validator monitoring tool that reads from a slow endpoint without surfacing latency, is actively harmful — it creates false confidence.

// Surface data freshness explicitly — don't let tools be quietly wrong
interface AccountData {
  balance: number;
  slot: number;
  fetchedAt: number; // unix ms
}

async function getAccountWithFreshness(pubkey: PublicKey): Promise<AccountData> {
  const { context, value } = await connection.getAccountInfoAndContext(pubkey);

  return {
    balance: value?.lamports ?? 0,
    slot: context.slot,
    fetchedAt: Date.now(),
  };
}

// In your UI: show when data is stale
const isStale = Date.now() - data.fetchedAt > 10_000; // 10s
// Render a warning badge rather than silently showing old numbers

Block's solution — baking test scaffolding into default templates — translates to Solana tooling as: any scaffold that reads on-chain data should include a staleness check and a visible indicator by default, not as an optional improvement.

Lesson 5: the MCP-backed CLI pattern

Block's deployment CLI is backed by an MCP server and distributed as an internal skill. This means the agent that builds the app and the infrastructure that deploys it share a common interface — the agent can scaffold, build, and deploy without leaving the conversation.

For Solana, the same pattern is available today. Solana has an official MCP server that exposes program deployment, account reads, and transaction simulation as agent-callable tools. The gap Block closed internally — "build it and safely ship it from the same session" — is closable in the public Solana ecosystem using the same architecture.

// claude_desktop_config.json — Solana MCP for agent-driven deployment
{
  "mcpServers": {
    "solana": {
      "command": "npx",
      "args": ["-y", "@solana/mcp-server"],
      "env": {
        "SOLANA_RPC_URL": "https://mainnet.helius-rpc.com/?api-key=...",
        "SOLANA_KEYPAIR_PATH": "~/.config/solana/id.json"
      }
    }
  }
}

The agent builds the Anchor program. The MCP server compiles it. The agent runs solana program deploy via the MCP tool. No terminal switching. No credential copy-paste. The security boundary is the MCP server's configuration — the agent can only deploy to the clusters and with the keypairs the server exposes.

The pattern in summary

Block's learnings reduce to four principles that apply directly to Solana tooling:

1. Credentials belong in the platform, not the app. RPC keys, wallet keys, and program deploy keypairs should never be in application code or client bundles.
2. Constraints beat choices. Opinionated scaffolds that make infrastructure decisions are safer than flexible ones that leave them to the developer.
3. Auth is infrastructure, not a feature. SIWS gives every Solana tool wallet-native authentication with no additional dependencies.
4. Surface data quality explicitly. Any tool that reads on-chain state should show slot number, fetch timestamp, and a staleness warning rather than presenting stale data as current.

Block shipped 1,000 apps across 50 departments by building the deploy gap infrastructure once. The Solana ecosystem has most of the pieces — SIWS, the MCP server, Helius RPC, Cloudflare Workers for proxy layers. The missing piece is the opinionated scaffold that assembles them with the right defaults, so the AI that builds the app and the platform that deploys it share the same security invariants.