What is the benefits of having your own on-chain program?

External question — Solana Stack Exchange Author: Yunus Oksuz Original post: https://solana.stackexchange.com/questions/20192 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. there are a few similar questions on the platform but my questions is a little related with jito on point of transaction output validation view. when i was going through the transactions on solscan i see that some of the accounts are sending their swap transactions to their own on-chain program (i assume they owned the program). There is no other instructions or inner instructions other than the basic dex swap. I am wondering that, what kind of benefit they have sending the basic swap transction to the their onchain program? You can say that: verify and validate result of the transaction. It is acceptable but does Jito do the same ? Isn't it simulate your tx bundle before execution with a small amount of tip ? So if jito exists and does the same, why do people use their own program for execution swap/arbitrage ? ps: rust will have me according to your answers *swh

External answer — Solana Stack Exchange Author: Dan Original post: https://solana.stackexchange.com/a/21080 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Jito can sometimes be down or slow. So being able to use your own program can be faster and more reliable than using something like jito

External answer — Solana Stack Exchange Author: Hamid Burek Original post: https://solana.stackexchange.com/a/24301 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Jito and a custom program do different things. Jito gives you bundle atomicity, a private relay, and off-chain sim. That controls inclusion . Your program gives you post-condition checks at execution time. That controls outcome . The sim runs on pre-slot state. By the time your tx actually lands, the pool may have moved. Jito won't revert your swap if slippage eats the profit. A require! in your own program will: dex::swap(ctx, ...)?; require!(out_after - out_before >= min_profit, NotProfitable); Two other reasons people wrap it: Flash-loan arb needs single-tx atomicity (borrow, swap, swap, repay in one tx), not bundle atomicity. Jito only helps when a Jito validator is the leader, which is roughly half the slots. The other half you're on your own, so the on-chain guard is your only protection. Arb bots usually run both: program gates the fill, Jito gates the ordering.