Repository navigation
Conversation
The orderbook read the compute unit limit of a creation only to price its priority fee. A creation that declares too few units fails on chain, and the funder pays the base fee for no order. The `[sponsoring]` section gets two keys. A creation that declares a limit outside them is rejected with `InvalidTransaction`. A creation that declares no limit is not bounded. - `min-compute-unit-limit`, default 0 - `max-compute-unit-limit`, default 1400000
…ames The two runtime `Sponsoring` fields and the test server helper carry their meaning in their names. The configuration doc comments keep the reason for each bound.
|
Claude finished @tilacog's task in 31s —— View job ReviewThe change looks correct. The bounds apply only to a declared limit, they're checked after the priority fee ceiling and before the bundle is parsed, and the defaults keep today's behaviour up to 1,400,000. The new test covers both edges and the undeclared case. I left one inline comment: the config doesn't check that I didn't run the tests in this job. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
🤖 Claude reviewed this PR. Any issues are posted as inline comments on the relevant lines.
Won't run when: the PR is a draft, the author is a bot or lacks write access, or the |
…are inverted With the minimum above the maximum, validate refuses every sponsored creation that declares a limit.
jmg-duarte
left a comment
jmg-duarte
left a comment
There was a problem hiding this comment.
LGTM but I think the error message should be rethought
There was a problem hiding this comment.
The error implies that the transaction should not be sponsored but still go through
Description
Until now,
validateused the compute unit limit of a sponsored creation only inside the priority fee product. A creation that declaredSetComputeUnitLimit(1)passed placement, failed on chain, and the funder paid the base fee for no order.With this PR, the orderbook now bounds a declared limit with two configuration values.
A creation that declares no limit passes, just as before, since it will end up using the Solana runtime defaults, which are acceptable.
Changes
infra/config.rs:sponsoring.min-compute-unit-limit(default 0) andsponsoring.max-compute-unit-limit(default 1,400,000, the most a transaction can consume). The defaults accept every creation that passes today with a limit of at most 1,400,000.create_order/mod.rs:validatereturnsInvalidTransactionwhen a declared limit is below the minimum or above the maximum.infra/api/mod.rs,run.rs: the runtimeSponsoringcarries the two bounds.example.toml: documents both keys.How to test
cargo nextest run -p solana-orderbookcreate_order_bounds_the_declared_compute_unit_limit: with a minimum of 10,000 it refuses 9,999 and accepts 10,000 and an undeclared limit. With the defaults it accepts 1,400,000 and refuses 1,400,001.Related Issues
BE-526