docs: add jito bundle example code

[amilz]

Add sample code for running a mainnet Kora node with Jito Bundle Support. Corresponding guide PR coming shortly.

Closes PRO-635

---

Important

Add example code and configuration for running a Kora node with Jito Bundle support on Solana mainnet.

• Example Code:
  • Adds index.ts in client/src to demonstrate creating and submitting Jito bundles using Kora.
  • Implements functions for client initialization, key setup, transaction creation, and bundle submission.
• Configuration:
  • Adds kora.toml and signers.toml in server for Kora node configuration.
  • Includes .env.example for environment variable setup.
• Scripts and Documentation:
  • Adds start-kora.sh script to start Kora with Jito support.
  • Provides README.md in jito-bundles with a demo guide and sample output.

^{This description was created by for d53db39. You can customize this summary. It will automatically update as commits are pushed.}

[linear]

PRO-635 Bundles Sample Code

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to a019955 in 1 minute and 54 seconds. Click for details.

• Reviewed 508 lines of code in 7 files
• Skipped 1 files when reviewing.
• Skipped posting 5 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. examples/jito-bundles/README.md:50

• Draft comment:
  Consider adding a newline at end of file for POSIX compliance.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment is about POSIX compliance regarding a trailing newline. While technically correct that POSIX text files should end with a newline, this is an extremely minor issue. The rules state "Do NOT make comments that are obvious or unimportant." This falls into the "unimportant" category - it's a README.md file, not critical code, and the lack of a trailing newline won't cause any functional issues. Most modern editors and tools handle this gracefully. This is the kind of nitpicky comment that would likely be caught by linters or formatters if the project cares about it, and it doesn't require human review attention. Some projects do enforce trailing newlines via linters and consider it important for consistency. This could be a legitimate project standard that should be followed. Additionally, some diff tools can show confusing output when files lack trailing newlines. While some projects enforce this, the comment doesn't reference any specific project standard or linter rule. If this were truly important to the project, it would be caught automatically by CI/linters. This is an unimportant stylistic comment that doesn't warrant manual review attention. This comment should be deleted. It's about a minor stylistic issue (missing trailing newline) that is unimportant and would be caught by automated tools if the project cares about it. It doesn't meet the bar for requiring a code change in a manual review.

2. examples/jito-bundles/client/src/index.ts:107

• Draft comment:
  Hardcoded 'lastValidBlockHeight' set to 0n is demo-specific. For production, ensure to use the correct block height.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

3. examples/jito-bundles/client/src/index.ts:185

• Draft comment:
  Polling loop immediately breaks after one iteration (simulated). Ensure real status polling logic is implemented for production.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

4. examples/jito-bundles/scripts/start-kora.sh:1

• Draft comment:
  Consider adding a shebang (e.g., #!/bin/bash) at the top of the script for better portability.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% This is a code quality suggestion about adding a shebang line. While technically correct that shebangs improve portability, this falls into a gray area. The rules say "Do NOT comment unless there is clearly a code change required" and "Do NOT make comments that are obvious or unimportant." Adding a shebang is a best practice but not strictly required - the script could work without it if executed with bash start-kora.sh or if it has execute permissions and bash is the default shell. This is more of a "nice to have" suggestion rather than a clear code change requirement. The comment uses "Consider" which is softer language, suggesting it's optional rather than required. However, shebangs are a widely accepted best practice for shell scripts, and this is a clear, actionable suggestion that would improve the code quality. The rules do say "Comments that suggest code quality refactors are good! But only if they are actionable and clear." This comment is both actionable and clear. While it is actionable and clear, the rules emphasize not commenting unless there is "clearly a code change required." The word "Consider" in the comment itself suggests this is optional, not required. The script will function without a shebang in most contexts, making this more of a style preference than a necessary fix. This comment is a reasonable code quality suggestion but uses soft language ("Consider") indicating it's optional rather than required. Given the emphasis on only keeping comments where code changes are clearly required, and the instruction to err on the side of deleting when unsure, this should be removed.

5. examples/jito-bundles/server/kora.toml:31

• Draft comment:
  The 'price_source' is set to 'Mock'. Update this configuration for production environments as needed.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is informative and suggests a change for production environments, which is not specific to the current code change. It doesn't ask for a specific code change or test to be written, nor does it point out a potential issue with the current code.

Workflow ID: wflow_czrd9MRBhUuat6xb

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed d53db39 in 49 seconds. Click for details.

• Reviewed 129 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 5 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. examples/jito-bundles/client/src/index.ts:49

• Draft comment:
  Updated log message step number from [1/5] to [1/4] to reflect the new 4-step flow.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

2. examples/jito-bundles/client/src/index.ts:62

• Draft comment:
  Adjusted setupKeys log step to [2/4] for consistency.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

3. examples/jito-bundles/client/src/index.ts:78

• Draft comment:
  Updated bundle transactions log step to [3/4] to match the revised demo steps.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

4. examples/jito-bundles/client/src/index.ts:143

• Draft comment:
  Removed signBundle and submitAndTrackBundle functions to simplify the demo; using client.signAndSendBundle directly.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

5. examples/jito-bundles/client/src/index.ts:166

• Draft comment:
  Revised main function to combine signing and sending in a single step with signAndSendBundle, updating the log to [4/4].
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

Workflow ID: wflow_YHahwocqc0JfD7Up

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[dev-jodee]

amazing