RAVEN. / transaction boundaryRAVEN. / transaction boundaryAgents can now produce unsigned Solana transactions over HTTP and hand them to signers, relayers, and landing services. Raven sits before all of that. It is a pre-action receipt gate — not a transaction builder, signer, simulator, relayer, router, or landing optimizer. Machine-readable: /transaction-boundary-policy.json.
An unsigned transaction is an action artifact. Simulation success tells you a transaction may execute — not that the token is acceptable. Landing success, RPC/relayer success, and priority fees or low latency prove delivery speed, nothing else. A signer must not sign merely because an agent produced a base64 transaction.
correct: candidate token → Raven receipt → policy → builder/signer/submitter
PROHIBITED: candidate token → builder → simulation → signer → maybe check Raven later
If Raven checked mint A and the generated transaction touches mint B, another pool, or another metadata account, the receipt does not cover the action — block or re-verify. Match chain, mint, tokenProgram, and metadata/pool where applicable. Builder drift (the route changes after verification) is a coverage gap or a re-verification trigger, never an implicit pass.
The faster agents move, the more staleness matters. Re-verify immediately before signing or submission; delayed execution re-verifies at execution time; relayer retries past the staleness window re-verify; cached receipts are display-only. Scheduled agents follow the same rule — a cron firing at time X is not proof of freshness, and catch-up runs after downtime must not bulk-proceed on old receipts. Drills 35–42 rehearse this boundary: failure drills.