This document contrasts two distinct architectural approaches for implementing automated cross-entity interactions (such as recurring payments or conditional transfers) on high-performance blockchains.
- TON (The Open Network) employs an Actor Model where every wallet is a smart contract. Automation is achieved via asynchronous message passing and internal state transitions.
- Solana employs a Delegation (Pull) Pattern on top of a stateless Account Model. Automation is achieved by authorizing a third-party system to execute transactions on your behalf.
The core difference lies in agency:
- On TON, your wallet is an agent that "decides" to act based on incoming triggers.
- On Solana, your wallet is a resource that "allows" external agents to act upon it.
To illustrate the technical differences, we will solve the same specific problem on both chains:
Goal: A user wants to subscribe to a service (System B). Requirement: When the service (System B) requests payment, the User's Wallet (Wallet A) should automatically transfer 10 tokens to System B, provided it matches the agreed-upon frequency and amount. Constraint: The user should not need to manually sign the transaction every month.
In TON, "Wallet A" is not just a ledger entry; it is a running program (Smart Contract).
- User Wallet (Contract A): A smart contract controlled by the user's private key and its own internal logic code.
- System Operator (Contract B): A smart contract representing the subscription service.
- User Action: User sends an external message (signed) to Wallet A.
- Wallet A Execution: Wallet A processes the message. It updates its own persistent state (long-term memory):
authorized_operator = Address(System B)max_amount = 10 TONinterval = 30 dayslast_paid = 0
- System Action: System B sends an internal message to Wallet A with the opcode
request_payment. - Asynchronous Delivery: The network routes this message to the shard containing Wallet A.
- Wallet A Wakes Up: The message arrives at Wallet A's address. This triggers the
recv_internal()function in Wallet A's code. - Internal Verification: Wallet A's code executes:
// Pseudo-code inside Wallet A if (sender_address == authorized_operator) { if (now() - last_paid > interval) { send_tokens(sender_address, 10); last_paid = now(); // Update memory } }
- Result: Wallet A creates a new outgoing message with the funds.
- Push-Reaction: The system "pokes" the wallet, and the wallet "reacts."
- Encapsulated Logic: The rules ("pay only every 30 days") live inside the user's wallet contract.
- No Delegation: The user never gives "permission" to System B to take money. They instruct their own agent (Wallet A) to give money when asked.
In Solana, a standard wallet is a "System Account" with no code. It cannot "think" or "react." Therefore, we must use the Token Program's delegation features.
- User Wallet (Account A): A simple data storage account holding tokens.
- System Operator (Keypair B): An automated bot/server controlled by the service.
- SPL Token Program: The standard "engine" that manages all token balances on Solana.
- User Action: User signs a transaction interacting with the SPL Token Program.
- Instruction: The instruction is
Approve(delegate=SystemB, amount=100). - State Change: The Token Program updates the metadata associated with Wallet A's token account:
delegated_authority = Address(System B)delegated_amount = 100
- System Action: When payment is due, System B (the bot) creates a transaction.
- Instruction: The instruction is
TransferChecked. - Signer: The transaction is signed by System B (not User A).
- Program Execution: The SPL Token Program receives the request.
- Validation: The Token Program checks:
- Is System B the delegated authority for Wallet A? (Yes)
- Is the requested amount <= delegated_amount? (Yes)
- Result: The Token Program decrements the balance of Wallet A and increments System B. It also decrements the
delegated_amount.
- Pull Model: System B actively "takes" the funds.
- External Logic: The rules (allowance limits) live in the generic Token Program, not in the user's wallet.
- Delegation: The user explicitly grants "power of attorney" to System B to sign for specific actions.
| Feature | TON (Smart Contract Wallet) | Solana (Delegation Pattern) |
|---|---|---|
| Philosophy | Object-Oriented: Objects (Wallets) have methods and internal state. | Functional / Database: Programs act on passive data entries (Accounts). |
| Control | Internal: "I pay you because I decided to." | External: "I allow you to take from me." |
| Logic Customization | Infinite: You can code any rule (e.g., "pay only if it's raining"). | Limited: Restricted to what the Token Program supports (amount limits). |
| State Storage | Inside the Wallet contract (c4 storage). |
Inside the Token Account metadata. |
| Security Risk | Code Bug: If your wallet code has a bug, you could lose funds. | Key Leak: If System B's key is leaked, they can drain the allowance. |
| Cost | Computation cost is paid by Wallet A (usually) during execution. | Transaction fee is paid by System B (the initiator). |
This section grounds the architectural theory in 2025 production metrics and live case studies.
When choosing an architecture for automated payments, the cost and finality guarantees of transactions are critical factors.
| Metric | TON (The Open Network) | Solana |
|---|---|---|
| Architectural Cost | Heavy. Sender pays for smart contract execution (compute + storage). | Light. Sender pays only for signature verification + state update. |
| Avg. Tx Fee (USD) | ~$0.0055 - $0.02 [1][2] | ~$0.00025 [3][4] |
| Real-Time TPS | ~4,300 - 104,000* (Highly variable due to sharding) [2][5] | ~800 - 5,000 (avg/peak) [6] |
| Time to Finality (TTF) | ~6 seconds [5] | ~2.5 seconds (Finalized) |
Clarification on Solana Finality:
- Slot Time (~0.4s): This is the block production time. A transaction can be optimistically confirmed in this timeframe, which is often sufficient for low-value, non-critical actions.
- Finalized (~2.5s): This is the time until a supermajority of validators (2/3+) have voted on the block, making it irreversible. This is the true measure of finality and the correct metric to use when comparing against other blockchains' settlement guarantees for high-value applications. The previous figure incorrectly cited the much faster slot time.
- Cost Analysis: Triggering a subscription payment on Solana is approximately 20-80x cheaper than on TON. This makes Solana preferable for high-frequency micro-payments (e.g., streaming payments per second).
- Throughput: TON's "infinite sharding" theoretically allows higher max TPS (100k+), but in practice, standard payment throughput is comparable. Solana's lower latency (sub-second block times) offers a "snappier" user experience for point-of-sale interactions.
Implementation: Wallet v4 Plugins TON's integration into Telegram (via Mini Apps) leverages the "Smart Wallet" architecture directly. The most common standard is Wallet v4.[7]
- The Problem: A user playing a Telegram game wants to buy a "Monthly Battle Pass" for 5 TON. They don't want to sign a transaction every month.
- The Solution (Plugin):
- The Game App proposes a "Subscription Plugin" smart contract to the user.
- The User installs this plugin into their Wallet v4 contract via a single transaction.
- On-Chain Logic: The plugin code contains the rule: "Allow Game Contract X to request 5 TON every 30 days."
- Execution: The game server sends a simple message to the user's wallet every month. The wallet checks the installed plugin, validates the request against the plugin's rules, and sends the funds.[8][7]
- UX Benefit: This happens entirely in the background. The user gets a Telegram notification: "Payment of 5 TON successful," without opening their wallet.
Implementation: Tributary Protocol & Solana Pay Solana ecosystem projects like Tributary utilize the Delegation Pattern to build "Pull Payments".[9][10]
- The Problem: A merchant using Shopify wants to accept USDC for recurring SaaS subscriptions.
- The Solution (Token Delegation):
- Checkout: The user connects their wallet and approves a "Subscription mandate."
- Under the Hood: The wallet signs an
SPL Token Approveinstruction, delegating transfer authority to Tributary's protocol address for a specific monthly limit (e.g., 50 USDC). - Execution: Tributary's cron jobs (off-chain bots) monitor the due dates. When due, the bot sends a
TransferFromtransaction to the blockchain. - Settlement: The Solana Token Program verifies the delegation and moves funds from User → Merchant.[11][12]
- Merchant Benefit: Merchants avoid the 1.5-3% credit card processing fees, paying only the ~$0.00025 network fee.[12]
- TON is ideal for "Super App" integrations where the wallet is an intelligent extension of the user's identity (Telegram). The complexity is hidden inside the contract.
- Solana is ideal for "High-Frequency DeFi" and merchant payments where raw speed and rock-bottom fees are paramount. The complexity is handled by off-chain bots managing on-chain permissions.
The TON approach is more powerful but heavier: it requires every wallet to be a deployed contract. It mimics "real world" agency—a butler (your wallet) following your standing orders.
The Solana approach is lighter and faster: it uses standard, optimized primitives (Delegation). It mimics "direct debit" banking—you authorize a vendor to pull funds from your passive bank account.