Grid
Solana has the speed and cost structure needed for continuous automation. Developers aren’t short on ideas: DCA strategies, yield routing, conditional escrow, agentic trading.
The blocker has never been imagination. It’s been an implementation issue.
Building autonomous behaviors on Solana today requires writing, auditing, deploying, and maintaining bespoke programs. That’s protocol development time (months, even quarters) layered on top of product development time (features, iterations, experiments). Most teams can’t afford that investment.
Smart Transactions collapse time-to-market from “build a protocol” to “declare a rule set.”
Autonomy requires transactions that can execute themselves safely within strict, verifiable boundaries. Smart Transactions provide those boundaries. They turn every smart account into a programmable container for rules, price checks, signer permissions, allowed programs, and data conditions, all enforced atomically by Solana. This gives agents, automations, and financial workflows the ability to move capital deterministically, creating new user experiences and monetization avenues while maintaining user self-custody.
How Smart Transactions Work
A Smart Transaction attaches a rule set to a smart account. When a transaction is submitted, Solana evaluates those rules against live onchain state. If every rule passes, the transaction executes. If any rule fails, it reverts. There’s no off-chain gatekeeper, no trusted middleware. The chain enforces everything.
Rule sets are stored as onchain account data, not deployed programs. You can declare a Smart Transaction by sending a JSON rule set through our API or by interacting with the program directly. Either way, the rules live onchain and execute with full smart-contract guarantees.
You gain the enforcement model of a protocol without the development burden of becoming one.
Why Onchain Rule Enforcement Matters
Many key management services evaluate rules in a layer separate from the chain itself. When a user grants scoped access (e.g. spend up to $100 per day, only interact with these programs), the service checks those rules before signing. However, “before signing” is not the same as "enforced by the transaction."
The problem: if their offchain checks fail, behave unexpectedly, or are bypassed due to a bug or exploit, the transaction still executes. Funds move. You as the developer who integrated that service, may bear liability for user losses.
Offchain validation introduces a trust assumption between user intent and transaction execution. That trust assumption is a liability surface.
Onchain rule enforcement eliminates this. When a Smart Transaction’s rules are enforced at the protocol level, the checks happen atomically with transaction execution. The transaction either meets the constraints and executes, or it is rejected.
No separate validation layer that can fail independently. No race condition between checking rules and moving funds. No scenario where "the check passed but shouldn't have."
Smart Transactions enforce rules onchain. This is the difference between "we validate rules in our infrastructure before signing" and "invalid rules make the transaction itself invalid.
Programs → Smart Accounts → Smart Transactions
To see where Smart Transactions fit, it helps to look at how Solana’s programmability has matured.
Programs (Smart Contracts) put logic onchain. They define what can happen and the conditions under which it can happen. They’re powerful, but writing, auditing, and maintaining them is expensive.
Smart accounts made ownership programmable. Multisig, thresholds, session keys, spend caps, recovery flows, all achievable without deploying new programs. They answered the question: “Who can act on this account?”
Smart Transactions make behavior programmable. They answer a different question: “What can this account do, under what conditions, and what must be true for execution to proceed?”
This is programmable behavior, not just programmable ownership.
Rules Smart Transactions Can Enforce
Smart Transactions work by defining what must be true for a transaction to be valid. Every rule is a constraint. The transaction executes only if all constraints are satisfied at execution time.
Required signers. The rule set can require that specific keys have signed the transaction. This is how developers (their bots or their agents) gain permission to trigger the behavior. The user configures a rule set that includes the developer's key as a required signer for a specific, bounded set of actions.
Allowed programs. Rules specify which programs can be called, defined by program ID. Interactions with any other program cause the transaction to fail.
Allowed instructions. Within permitted programs, rules specify which instructions are allowed, defined by a discriminator. Swap yes, withdraw no.
Required accounts. Rules can mandate that certain accounts are included in the transaction: the user's token account, a particular liquidity pool, an oracle price feed.
Account data validation. Rules can inspect the data inside required accounts and enforce constraints:
Balance checks. Only execute if an account balance is at least X.
Boolean flags. Only execute if a flag in an account is true (or false).
Pubkey validation. Only execute if a specific pubkey appears in an account's data field. Ensures you're interacting with the correct pool, vault, or position.
Numeric thresholds. Only execute if a utilization rate, price, or other numeric field falls within bounds.
These constraints protect both users and developers. Users know their funds can only move under conditions they've approved. Developers know their strategies won't execute in dangerous edge cases.
Join the Private Beta
Smart Transactions are in production testing with select teams. We're onboarding more builders every day.
Early access means you'll help shape templates, patterns, and the roadmap. If you're building DeFi, fintech, wallets, automation layers, or agentic systems on Solana, this is designed for you.
