[RC] 2.2.0

[dev-jodee]

Important

This pull request adds a new getVersion method, deprecates the transferTransaction endpoint, and updates tests and configurations accordingly.

• Features:
  • Add getVersion method to retrieve server version in client.ts and rpc.rs.
  • Deprecate transferTransaction endpoint, update related tests in integration.test.ts and transfers.rs.
• Testing:
  • Update unit and integration tests to cover new getVersion method in unit.test.ts and integration.test.ts.
  • Modify tests to handle deprecated transferTransaction endpoint in transfers.rs and token_2022_test.rs.
  • Add new test configurations in auth-test.toml, fee-payer-policy-test.toml, and other .toml files.
• Configuration:
  • Update .toml files to reflect new features and deprecations, including kora-test.toml and paymaster-address-test.toml.

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

📊 Unit Test Coverage

Unit Test Coverage: 81.9%

View Detailed Coverage Report

---

[github-actions]

📊 TypeScript Coverage Report

Coverage: 80.3%

View detailed report

Coverage artifacts have been uploaded to this workflow run.
View Artifacts

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 818d8bd in 6 minutes and 21 seconds. Click for details.

• Reviewed 7775 lines of code in 96 files
• Skipped 13 files when reviewing.
• Skipped posting 28 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/x402/demo/.env.example:1

• Draft comment:
  Consider adding inline comments explaining required ENV keys (e.g. KORA_SIGNER_ADDRESS, KORA_SIGNER_PRIVATE_KEY) to help new operators.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. examples/x402/demo/api/src/api.ts:12

• Draft comment:
  Good use of typed Resource template literal. Ensure that env values match expected format.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

3. examples/x402/demo/api/src/api.ts:27

• Draft comment:
  The check for KORA_SIGNER_ADDRESS is explicit; consider logging which variable is missing to aid debugging.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

4. examples/x402/demo/facilitator/src/facilitator.ts:48

• Draft comment:
  Endpoints for verify and settle are straightforward; consider adding more detailed logging for production diagnostics.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

5. sdks/ts/src/client.ts:250

• Draft comment:
  Marking transferTransaction as deprecated is good. Ensure that users are encouraged to use getPaymentInstruction.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

6. sdks/ts/src/client.ts:315

• Draft comment:
  The getPaymentInstruction method correctly derives ATAs. Verify that getTransferInstruction produces the expected structure.
• Reason this comment was not posted:
  Confidence changes required: 10% <= threshold 50% None

7. sdks/ts/test/integration.test.ts:140

• Draft comment:
  Integration tests are thorough. Consider also testing boundary conditions for fee estimation and payment instruction math.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

8. sdks/ts/test/unit.test.ts:20

• Draft comment:
  Unit tests correctly mock global fetch; ensure that error cases (e.g., malformed JSON) are also tested.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

9. tests/rpc/transfers.rs:6

• Draft comment:
  RPC transfer tests assume unsigned transactions. Validate that simulation of the transaction returns no error.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

10. tests/src/common/fixtures/auth-test.toml:5

• Draft comment:
  Auth configuration includes API key and HMAC; ensure associated tests cover header inclusion.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

11. tests/src/common/fixtures/fee-payer-policy-test.toml:55

• Draft comment:
  This config file sets all fee payer permissions to false; verify downstream tests correctly handle restrictive policies.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

12. tests/src/common/fixtures/kora-test.toml:13

• Draft comment:
  Configuration for integration tests is detailed. Verify that 'estimate_transaction_fee' flag and get_version flag are set as intended.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

13. tests/src/common/fixtures/paymaster-address-test.toml:2

• Draft comment:
  Paymaster address is set to a specific value; ensure tests differentiate between fee payer and payment address.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

14. tests/tokens/token_2022_test.rs:12

• Draft comment:
  Token 2022 transfer tests are comprehensive. Confirm that the unsigned transaction decoding uses TransactionUtil correctly.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

15. tests/src/common/fixtures/kora-free-test.toml:1

• Draft comment:
  This file is for free pricing tests. Ensure 'price' is set to 'free' to bypass fee validations in tests.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

16. tests/src/common/fixtures/kora-test.toml:1

• Draft comment:
  Configurations for kora tests include custom settings. Verify that enabled_methods include get_version.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

17. tests/src/common/fixtures/paymaster-address-test.toml:1

• Draft comment:
  Paymaster address test config is set with both signer and payment address. Ensure that tests properly compare these.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

18. sdks/ts/package.json:3

• Draft comment:
  Version set to beta; ensure documentation and changelog indicate changes for beta release.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

19. sdks/ts/src/client.ts:64

• Draft comment:
  Using crypto.createHmac for HMAC signature; consider parameterizing hash algorithm (currently hardcoded as 'sha256').
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

20. sdks/ts/src/types/index.ts:141

• Draft comment:
  Documentation for GetVersionResponse is clear; ensure consistent formatting with other response types.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

21. sdks/ts/test/integration.test.ts:227

• Draft comment:
  Test for getPaymentInstruction is detailed; consider verifying payment instruction data bytes in addition to account addresses.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

22. sdks/ts/test/unit.test.ts:85

• Draft comment:
  Unit tests adequately cover basic RPC methods. Consider adding tests for HMAC header generation when hmacSecret is provided.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

23. tests/src/common/fixtures/auth-test.toml:1

• Draft comment:
  Auth test config looks good. Consider adding comments to indicate which environment variable names must be set by users.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

24. CHANGELOG.md:19

• Draft comment:
  The changelog entry "- sign if create ata ix found" on this line seems potentially unclear. It might be a typographical error (e.g. missing a word or using an incorrect abbreviation). Could you please double-check and clarify the intended wording?
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to double-check and clarify the wording of a changelog entry, which violates the rule against asking the author to confirm or explain their intention. The comment does not provide a specific code suggestion or ask for a test to be written, so it should be removed.

25. CLAUDE.md:392

• Draft comment:
  Typographical: The ComputeBudget address now appears to have one less '1' than before. Please confirm if this is intentional or a typo.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

26. README.md:67

• Draft comment:
  Typographical suggestion: The phrase "Get Kora running locally minutes" in this line seems awkward. Consider inserting a preposition (e.g., "in minutes") for clarity.
• Reason this comment was not posted:
  Comment was on unchanged code.

27. examples/deploy/kora.toml:97

• Draft comment:
  There is an extra '#' in the comment on the margin configuration (line 97). Consider removing the extra '#' to clean up the comment.
• 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% The comment is pointing out a minor formatting issue - there's an extra # in the comment on line 97. While this is technically correct, I need to consider if this meets the bar for a useful comment. The rules state "Do NOT make comments that are obvious or unimportant." A double # in a comment is a very minor cosmetic issue that doesn't affect functionality at all. It's purely a formatting/style issue. The rules also say to only comment if there's "clearly a code change required" and not to make "obvious or unimportant" comments. This seems to fall into the "unimportant" category - it's just a minor typo in a comment that has no functional impact. While the comment is technically correct about the extra #, this is an extremely minor cosmetic issue. The rules explicitly state not to make obvious or unimportant comments, and a double # in a comment seems to fall into that category. It's not affecting functionality or clarity in any meaningful way. You're right - this is a trivial formatting issue that doesn't warrant a review comment. While it's technically correct, it's the kind of minor typo that doesn't meet the bar for "clearly a code change required." It's unimportant and obvious. This comment should be deleted. While technically correct about the extra #, it's an unimportant cosmetic issue that doesn't meet the bar for review comments. The rules explicitly state not to make obvious or unimportant comments.

28. examples/x402/demo/api/src/api.ts:69

• Draft comment:
  Typo/Formatting: The file does not end with a newline. Please add a newline at the end of the file to adhere to standard formatting practices.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% This comment is about a very minor formatting issue - missing a newline at the end of the file. According to the rules, I should not comment on things that are "obvious or unimportant" and should only comment if "there is clearly a code change required." While some linters enforce this, it's typically a very minor style issue. More importantly, this type of formatting issue would almost certainly be caught by automated linting tools (ESLint, Prettier, etc.) during the build process, and the rules explicitly state "Do NOT comment on anything that would be obviously caught by the build." Missing newlines at end of file are commonly caught by linters and formatters. However, not all projects have linters configured to catch this, and it is a legitimate style convention in many codebases. Some teams consider this important for POSIX compliance and clean git diffs. The comment does suggest a clear, actionable change. While it's true that not all projects have this configured, the rule explicitly states to not comment on things that would be "obviously caught by the build." Most modern TypeScript/JavaScript projects use ESLint or Prettier which catch this by default. Additionally, this falls under "obvious or unimportant" - it's a trivial formatting issue that doesn't affect functionality. The rules emphasize only commenting when there's a clear code change required, not formatting nitpicks. This comment should be deleted. It's about a minor formatting issue (missing newline at EOF) that would typically be caught by automated linting tools, and it falls under the category of "obvious or unimportant" comments that the rules explicitly say to avoid.

Workflow ID: wflow_zH4z4w3sl5sdqBpr

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

[devin-ai-integration]

Devin Review found 4 potential issues.

View 10 additional findings in Devin Review.

[devin-ai-integration]

🟡 CONTRIBUTING.md references make commands instead of just after Makefile-to-justfile migration

The newly added CONTRIBUTING.md instructs contributors to use make build, make check, make unit-test, make integration-test, make install-ts-sdk, make build-ts-sdk, make unit-test-ts, and make check — but the PR deletes the Makefile and all makefiles/ and migrates everything to justfile. Contributors following these instructions will get make: *** No rule to make target errors. The CLAUDE.md and README.md were correctly updated to use just commands, but CONTRIBUTING.md was not.

Suggested change

	2. Build all packages: `make build`
	3. Run formatting and lint checks: `make check`
	4. Run unit tests: `make unit-test`
	5. Run integration tests: `make integration-test`
	## TypeScript SDK
	```shell
	make install-ts-sdk
	make build-ts-sdk
	make unit-test-ts
	```
	## Before Submitting
	- Run `make check` (formatting + clippy)
	- Run `make unit-test`
	1. Install Rust and Cargo
	2. Build all packages: `just build`
	3. Run formatting and lint checks: `just check`
	4. Run unit tests: `just unit-test`
	5. Run integration tests: `just integration-test`
	## TypeScript SDK
	```shell
	just install-ts-sdk
	just build-ts-sdk
	just unit-test-ts

Before Submitting

• Run just check (formatting + clippy)
• Run just unit-test
• Use conventional commits (feat:, fix:, chore:, etc.)

<!-- devin-review-badge-begin -->
<a href="https://app.devin.ai/review/solana-foundation/kora/pull/288" target="_blank">
  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="https://static.devin.ai/assets/gh-open-in-devin-review-dark.svg?v=1">
    <img src="https://static.devin.ai/assets/gh-open-in-devin-review-light.svg?v=1" alt="Open in Devin Review">
  </picture>
</a>
<!-- devin-review-badge-end -->

---
*Was this helpful? React with 👍 or 👎 to provide feedback.*

[devin-ai-integration]

🔴 Usage limit check-and-increment has TOCTOU race condition allowing limit bypass

In UsageTracker::check_and_record (crates/lib/src/usage_limit/usage_tracker.rs:155-248), the two-phase approach first reads all counters via store.get() (line 202), checks them against limits, and only later increments them (lines 230-245). Between the get and the increment, concurrent requests from the same user can both read the same counter value, both pass the check, and both increment — allowing the user to exceed the configured limit. For example, with a limit of 5, two concurrent requests could both see count=4, both pass, and both increment to 5 and 6. With Redis, this should use atomic WATCH/MULTI or Lua scripting. With in-memory store, the lock is released between get and increment calls since they're separate await points.

Prompt for agents

In crates/lib/src/usage_limit/usage_tracker.rs, the check_and_record method (lines 155-248) has a TOCTOU race condition. The get() on line 202 and increment on lines 230-245 are separate non-atomic operations. Two concurrent requests can both pass the limit check and both increment, exceeding the limit.

To fix this:
1. For Redis (RedisUsageStore): Replace the separate get+increment with an atomic Lua script that checks the limit and increments in one operation. Something like: EVAL "local c = redis.call('INCR', KEYS[1]) if c > tonumber(ARGV[1]) then redis.call('DECR', KEYS[1]) return -1 end return c" 1 key max_limit
2. For InMemoryUsageStore: Hold the mutex lock across both the check and increment operations, or provide an atomic check_and_increment method on the UsageStore trait.
3. Add a new method to the UsageStore trait like `check_and_increment(key, max, expires_at) -> Result<(u32, bool), KoraError>` that atomically checks and increments.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 Bundle processes each transaction's usage limit independently, counting N times instead of once per bundle

In BundleProcessor::process_bundle at crates/lib/src/bundle/helper.rs:109-119, the usage limit check UsageTracker::check_transaction_usage_limit is called inside a loop for each transaction in the bundle. Since the usage tracker increments counters on each call (at crates/lib/src/usage_limit/usage_tracker.rs:230-245), a bundle of 5 transactions will consume 5 units from the user's transaction limit. This means a user with a limit of 5 transactions can only submit a single bundle of 5 transactions before being blocked. The usage check should either be done once for the entire bundle, or the increment should happen once (not per-transaction within a bundle).

Prompt for agents

In crates/lib/src/bundle/helper.rs lines 109-119, the usage limit check is called inside the per-transaction loop. This means a bundle of N transactions consumes N units from the user's transaction limit. Consider whether the intent is:

1. Each transaction in a bundle counts separately (current behavior) - if so, this is by design but should be documented clearly.
2. A bundle counts as one operation - move the usage check outside the loop to after all transactions are processed, calling it once.

If option 2 is desired, move the UsageTracker::check_transaction_usage_limit call to after the Phase 1 loop, passing the first resolved transaction and calling it once. The instruction-level counting should aggregate across all bundle transactions.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 BundleProcessingMode::CheckUsage borrows processing_mode in a loop without Copy

In BundleProcessor::process_bundle at crates/lib/src/bundle/helper.rs:110, the code matches on processing_mode inside a for loop. Since BundleProcessingMode contains Option<&'a str> (a Copy type via references), the if let pattern match on line 110 will re-borrow on each iteration. However, the match uses processing_mode by value in the if let which would move it on the first iteration. Actually, looking more carefully, BundleProcessingMode is an enum - the if let pattern match doesn't consume it because it's matching a reference pattern. This is actually fine in Rust since it's matching by reference. Let me retract this.

---

Was this helpful? React with 👍 or 👎 to provide feedback.