Jito 번들이란 무엇이고 무엇을 보장하지 않는가

Jito 번들은 최대 다섯 개의 솔라나 트랜잭션을 한 묶음으로 보내는 방식입니다. 작성한 순서대로 실행되고, 블록에 다 들어가거나 하나도 못 들어갑니다. 여기에 팁을 붙이면 그 묶음이 팁으로 블록 자리를 놓고 경매에 참여합니다.

• 번들 하나에는 팁 전송을 포함해 최대 다섯 개의 트랜잭션이 들어가며, 순차적이고 원자적으로 실행됩니다(Jito Labs 문서, 2026년 8월).
• 경매는 팁 액수 자체가 아니라 팁을 요청 컴퓨트 유닛으로 나눈 값으로 줄을 세웁니다. 가벼운 트랜잭션에 적은 팁이 무거운 트랜잭션에 큰 팁을 이깁니다.
• 2026년 8월 28일 11시 11분 UTC 기준으로 블록에 들어간 팁의 중앙값은 0.00000285 SOL, 95분위는 0.0003 SOL이었습니다.
• 원자성에는 실제 예외가 있습니다. 번들이 uncled 블록에 떨어지면 그 안의 트랜잭션이 따로 재전파될 수 있고, 거기에는 원자성도 되돌림 보호도 없습니다.
• Block Engine은 simulateBundle을 구현하지 않습니다. 2026년 8월 7일 다섯 개 리전에서 직접 측정했고 다섯 곳 모두 메서드 오류를 반환했습니다. 번들에는 사전 점검이 없습니다.

Jito 번들이란 무엇입니까?

Jito 번들은 서명된 솔라나 트랜잭션 한 개에서 다섯 개까지를 담은 목록이며, 검증자는 이를 여러분의 순서대로 통째로 실행하거나 아예 건드리지 않습니다. 일반 트랜잭션은 검증자에게 따로따로 도착해 스케줄러가 정한 순서로 자리를 잡습니다. 번들은 자기 묶음 안에서 그 불확실성을 없앱니다.

실제로 일하는 성질은 두 가지입니다. 첫째는 순차 실행으로, 두 번째 트랜잭션은 첫 번째가 남긴 상태를 봅니다. 둘째는 원자성입니다. 묶음 안에서 하나라도 실패하면 전체가 떨어지고 체인에는 아무것도 남지 않습니다. 이 두 가지가 있어서 토큰 생성과 첫 매수가 두 번의 기대가 아니라 한 번의 작업이 됩니다.

경로도 다릅니다. 일반 트랜잭션은 RPC 제공자를 거쳐 그 시점의 리더에게 갑니다. 번들은 Jito Block Engine으로 가서 경매에 들어가고, 이긴 조합만 검증자에게 전달됩니다. Jito Labs는 공개 Block Engine 리전을 여덟 곳 운영합니다. 도쿄, 프랑크푸르트, 뉴욕, 암스테르담, 더블린, 런던, 솔트레이크시티, 싱가포르입니다.

팁은 입장료입니다. Jito의 팁 계정 중 하나로 보내는 평범한 SOL 전송이고, 번들 안에 놓이며, 다섯 자리 중 하나를 차지합니다. 팁 없는 번들은 금액을 적지 않은 입찰과 같습니다.

팁을 올리면 번들이 반드시 블록에 들어갑니까?

아닙니다. 팁을 올리면 경매에서의 위치는 좋아지지만, 경매는 설계상 지는 쪽이 반드시 생깁니다. Jito는 정렬 규칙을 분명히 적어 두었습니다. 번들은 요청한 팁을 요청한 컴퓨트 유닛과 견주어 우선순위를 매기며, 팁 하나만 보지 않습니다. 이기는 것은 후함이 아니라 효율입니다.

이 한 문장이 낭비된 팁의 대부분을 설명합니다. 여러분의 번들이 140만 컴퓨트 유닛을 요청하고 0.001 SOL을 낸다면, 20만 유닛을 요청하고 0.0004 SOL을 내는 경쟁자가 블록의 단위 공간당 더 큰 가치를 제시하고 있는 것입니다. 컴퓨트 예산을 줄이는 편이 팁을 올리는 것보다 대체로 싸고, 둘은 같은 지렛대를 당깁니다.

팁을 올리기 전에 컴퓨트 상한을 정직한 값으로 맞추십시오. 경매는 팁을 요청 유닛으로 나눠 읽기 때문에, 알맞은 상한은 SOL을 더 써야 갈 수 있던 자리로 여러분을 올려 줍니다.

결과를 가르는 장치가 둘 더 있습니다. 경매는 50밀리초 간격으로 병렬로 돌고, 같은 계정을 건드리는 번들끼리는 한 경매 안에서 겨루지만 다른 계정을 건드리는 번들은 아예 마주치지 않습니다. 진짜 상대는 솔라나 전체가 아니라 같은 50밀리초 안에 같은 풀에 쓰는 사람들입니다.

두 번째 장치는 돈과 상관이 없습니다. 공개 Block Engine은 IP당 리전당 초당 한 번의 요청만 받고, 넘기면 429를 돌려줍니다. 하나의 주소에서 같은 번들을 여덟 리전에 뿌리는 도구는 이 천장에 부딪힙니다. 저희도 부딪혔습니다. 지금 저희 전송 경로는 엔드포인트마다 최소 1,100밀리초 간격을 지키고, 공개 풀보다 전용 엔드포인트를 먼저 씁니다.

지금 Jito 팁은 얼마입니까?

Jito가 받는 최소 팁은 1,000람포트, 즉 0.000001 SOL입니다. 실제로 블록에 들어가는 금액은 다르고 계속 움직입니다. 아래 표는 블록에 들어간 팁의 분위수를 Jito의 공개 tip floor API에서 직접 읽은 값이며, 시점은 2026년 8월 28일 11시 11분 UTC입니다. 가격표가 아니라 분포의 모양으로 읽으십시오.

블록에 들어간 팁 분위수	팁(SOL)	무엇을 사는가
최소 수용액	0.000001 SOL	경매 입장권일 뿐 그 이상은 아닙니다.
25분위	0.000001 SOL	들어간 번들의 4분의 1이 이만큼 또는 그 이하를 냈습니다.
50분위(중앙값)	0.00000285 SOL	평범한 상황입니다. 대부분의 번들은 다투고 있지 않습니다.
75분위	0.0000441 SOL	경쟁은 있지만 급하지는 않습니다.
95분위	0.0003 SOL	같은 계정을 놓고 벌이는 진짜 경쟁입니다.
99분위	0.001 SOL	봇들의 경주입니다. 사람이 여기까지 내는 건 대개 낭비입니다.

결정하기 전에 중앙값과 99분위의 간격을 보십시오. 약 350배이고, 그 구간의 거의 전부는 버튼을 누르는 사람과 상관이 없습니다. 저희 기본값은 일부러 낮습니다. 같은 API에서 95분위를 읽고 1.2를 곱한 뒤 결과를 0.00001 SOL과 0.02 SOL 사이로 묶습니다. 봇 전쟁의 급등이 사용자 지갑을 조용히 비우지 못하게 하려는 것입니다.

번들을 손으로 짠다는 것은 각 트랜잭션을 올바른 순서로 서명하고, 팁 전송을 끼워 넣고, 묶음을 다섯 개 아래로 유지한다는 뜻입니다. Bundled Trade는 그 묶음을 조립하고 팁을 붙여 한 번에 Block Engine으로 보냅니다. 없애 주는 것은 순서 실수이지 경매 위험이 아닙니다.

번들은 정말 원자적입니까?

네트워크가 받아들인 블록 안에서는 그렇습니다. 검증자는 번들을 통째로 실행하거나 실행하지 않으며, 실패한 트랜잭션 하나가 묶음 전체를 끌고 내려갑니다. 문서로 남은 예외가 하나 있고, 그것이 탐색기에서 번들 트랜잭션 옆에 빨간 표시가 보이는 이유입니다.

솔라나에는 건너뛴 슬롯이 생깁니다. 리더가 블록을 만들었지만 절대다수가 끝내 받아들이지 않는 경우입니다. Jito는 이런 블록을 uncled 블록이라고 부릅니다. 번들이 그런 블록에 떨어지면, 그 블록을 받은 쪽은 안의 트랜잭션을 다시 뿌릴 수 있습니다. 재전파된 사본은 일반 banking stage로 들어가고, 그곳은 번들의 원자성도 되돌림 보호도 인정하지 않습니다. 반쪽짜리 번들이 모두가 보는 앞에서 올라갔다 실패할 수 있습니다.

uncled 블록은 원자적이라던 번들을 둘로 쪼갤 수 있습니다. 두 번째 트랜잭션만 혼자 올라갔을 때 되돌릴 방법이 없는 전략은 만들지 마십시오. 드물지만 문서에 남은 결과이니 불가능한 일이 아닙니다.

질문	번들이 보장하는가	세부
내 순서대로 실행되는가	예	묶음 안에서 순차 실행됩니다.
전부 들어가거나 전부 안 들어가는가	예, 받아들여진 블록에서는	검증자가 묶음을 원자적으로 실행합니다.
번들이 블록에 들어가는가	아니오	경매입니다. 진 입찰은 버려집니다.
지면 팁은 돌아오는가	예	팁이 번들 안에 있어 못 들어간 번들은 아무것도 보내지 않습니다.
샌드위치로부터 안전한가	기본값으로는 아니오	Jito가 선택형 표식을 제공합니다. 아래에서 설명합니다.
uncled 블록을 견디는가	아니오	재전파된 사본은 원자성과 되돌림 보호를 잃습니다.

샌드위치 쪽에는 알아 둘 만한 답이 있습니다. Jito는 명령 안에 넣은, jitodontfront로 시작하는 유효한 공개키를 표식으로 받아들이고, 그 트랜잭션이 맨 앞 곧 인덱스 0에 있지 않은 번들은 Block Engine이 거부합니다. 번들 밖에서 벌어지는 일은 막지 못하며, 남의 뒤에 붙을 수 있는 선택지를 잃게 됩니다.

번들이 오류도 없이 사라진 이유는 무엇입니까?

번들이 조용히 사라지는 이유는 여러분이 쓰는 경로에 사전 점검이 아예 없기 때문입니다. Jito의 문제 해결 문서는 simulateBundle로 확인하라고 권하고, 그 메서드는 Jito-Solana RPC 노드에는 실제로 있습니다. 여러분의 번들을 받는 Block Engine에는 없습니다.

추측이 아니라 측정입니다. 2026년 8월 7일 프랑크푸르트, 뉴욕, 암스테르담, 솔트레이크시티, 런던 공개 리전에 simulateBundle을 호출했고 다섯 곳 모두 메서드를 찾을 수 없다는 오류를 돌려주었습니다. 저희 클라이언트는 이제 시뮬레이션이 실제로 돌았는지를 따로 보고합니다. 없는 메서드를 통과한 시뮬레이션으로 읽는 코드 경로는 사전 점검이 전혀 없으면서 그 사실을 모릅니다.

두 번째 이유는 짧은 기억입니다. getInflightBundleStatuses는 최근 5분만 압니다. 그 창을 넘어가면 번들 아이디가 invalid로 돌아오는데, 거절처럼 들리지만 거절이 아닙니다. Block Engine이 추적을 그만두었다는 뜻입니다. 그러면 진실의 출처는 하나만 남습니다. 트랜잭션이 체인에 있는지 없는지입니다.

번들이 잘못된 도구가 되는 때는 언제입니까?

대부분의 경우입니다. 번들은 두 개 이상의 트랜잭션을 절대 떼어 놓을 수 없을 때에만 복잡도값을 하고, 나머지 상황에서는 더해 주는 것이 없습니다. 단발 스왑에는 지킬 순서가 없고, 스스로 질 수도 있는 경매에서 얻을 것도 없습니다. 거기에 팁을 붙이는 건 나가지도 않은 경주의 표를 사는 일입니다.

번들이 보증처럼 팔리는 일이 잦으니, 한계 세 가지를 분명히 적습니다.

• 번들은 잘못된 트랜잭션을 살려 주지 않습니다. 슬리피지가 너무 좁거나 계정에 렌트 예치금이 없으면 묶음이 통째로 떨어지고, 여러분은 지연만 지불한 셈이 됩니다.
• 번들은 팁 대비 컴퓨트 비율이 더 좋은 빠른 경쟁자를 이기지 못하고, 졌다는 사실을 알려 주지도 못합니다. 경매에서 2등을 해도 오류 메시지는 나오지 않습니다.
• 번들은 여러분 자신으로부터 여러분을 지켜 주지 않습니다. 다섯 개라는 상한은 각 트랜잭션에 명령을 더 밀어 넣게 만들고, 그러면 요청 컴퓨트가 올라가며, 경매가 순위를 매기는 바로 그 효율이 떨어집니다.

생성과 첫 매수가 정말로 떨어질 수 없는 런치라면, 그것이 번들이 만들어진 이유입니다. Pump.fun Create and Bundle Buy는 민팅과 매수를 한 묶음에 넣고 하나의 입찰로 제출합니다. 런치는 계획한 대로 일어나거나, 아예 일어나지 않습니다.

이 글은 교육 목적이며 금융, 투자, 법률, 세무 자문이 아닙니다. 솔라나 토큰은 변동성이 매우 크고 대부분은 가치를 모두 잃습니다. 스스로 조사하시고, 잃어도 감당할 수 있는 범위를 넘는 자금은 걸지 마십시오. J Tools는 특정 토큰이나 거래를 추천하지 않습니다.

자주 묻는 질문

Jito 번들에는 트랜잭션이 몇 개 들어갑니까?

다섯 개이고 팁 전송이 그중 하나입니다. 실제 작업용으로는 네 개가 남습니다. Jito Labs가 이 한도를 문서로 남겼고, 저희 전송 경로는 여섯 번째 트랜잭션을 네트워크에 닿기 전에 거절합니다. Block Engine의 거절을 기다리는 왕복이 낭비이기 때문입니다.

번들이 못 들어가면 팁은 돌려받습니까?

돌려받습니다. 팁은 번들 안에 놓인 평범한 SOL 전송이라 번들이 실행될 때만 실행됩니다. 경매에서 진 번들은 아무것도 보내지 않고 체인에 비용도 남기지 않습니다. 잃는 것은 시간이지 SOL이 아닙니다.

Jito 최소 팁은 얼마입니까?

1,000람포트, 즉 0.000001 SOL입니다. 이것은 수용 기준선이지 블록 진입 기준선이 아닙니다. 2026년 8월 28일 11시 11분 UTC 기준 중앙값이 0.00000285 SOL이었으니, 평상시 현실적인 입장가는 문서상 최솟값의 몇 배입니다.

Jito 번들과 우선순위 수수료는 같은 것입니까?

다릅니다. 우선순위 수수료는 컴퓨트 예산 프로그램을 통해 검증자에게 지급되며 일반 경로의 단일 트랜잭션에 적용됩니다. Jito 팁은 번들 안의 SOL 전송으로 별도의 경매에 입찰합니다. 둘을 함께 쓸 수 있고 역할이 다릅니다.

탐색기에서 제 번들이 실패로 보이는 이유는 무엇입니까?

대개 uncled 블록 때문입니다. 네트워크가 받아들이지 않은 블록에 번들이 떨어졌고, 누군가 그 트랜잭션을 일반 banking stage로 다시 뿌렸으며, 그곳에는 원자성도 되돌림 보호도 없습니다. 탐색기가 보여 주는 것은 사본이지 여러분의 번들이 아닙니다.

번들이 샌드위치 공격을 막아 줍니까?

직접 켰을 때만 그렇습니다. 명령에 jitodontfront로 시작하는 공개키를 넣으면 Block Engine은 여러분의 트랜잭션이 맨 앞이 아닌 번들을 모두 거부합니다. Jito 번들 안에서의 새치기를 막을 뿐, 바깥에서 벌어지는 일에는 관여하지 않습니다.

이 글에 쓴 자료입니다. 번들 한도와 경매 규칙, 요청 제한, uncled 블록은 Jito Labs 저지연 트랜잭션 전송 문서, 팁 분위수는 Jito tip floor API, 기본 트랜잭션 모델은 솔라나 트랜잭션 문서입니다. 이어서 읽을 글은 솔라나 우선순위 수수료를 얼마나 낼지, Jupiter, Raydium, Orca 비교, Pump.fun 대신 쓸 런치패드입니다.

J Tools 팀이 작성했습니다. 토큰 생성부터 온체인 지갑 분석까지 40개가 넘는 솔라나 도구를 실제 운영 환경에서 만들고 굴리며, 이론이 아니라 메인넷에서 본 것을 씁니다. 발행: 2026년 8월 28일. 최종 검토: 2026년 8월 28일.