Skip to content

SIMD-0452: Charge CUs for ABIv0/v1 Instructions#452

Open
Lichtso wants to merge 1 commit intosolana-foundation:mainfrom
Lichtso:charge-cus-for-abi-v0-and-v1-instructions
Open

SIMD-0452: Charge CUs for ABIv0/v1 Instructions#452
Lichtso wants to merge 1 commit intosolana-foundation:mainfrom
Lichtso:charge-cus-for-abi-v0-and-v1-instructions

Conversation

@Lichtso
Copy link
Contributor

@Lichtso Lichtso commented Jan 26, 2026

No description provided.

@simd-bot
Copy link

simd-bot bot commented Jan 26, 2026

Hello Lichtso! Welcome to the SIMD process. By opening this PR you are affirming that your SIMD has been thoroughly discussed and vetted in the SIMD discussion section. The SIMD PR section should only be used to submit a final technical specification for review. If your design / idea still needs discussion, please close this PR and create a new discussion here.

This PR requires the following approvals before it can be merged:

Once all requirements are met, you can merge this PR by commenting /merge.

@Lichtso Lichtso force-pushed the charge-cus-for-abi-v0-and-v1-instructions branch from a22e932 to dd7de8d Compare January 26, 2026 13:56
@Lichtso Lichtso changed the title Charge CUs for ABIv0/v1 Instructions SIMD-0452: Charge CUs for ABIv0/v1 Instructions Jan 26, 2026
Comment on lines +98 to +100
It will break existing TX building as the CUs required will be significantly
increased. To counter this we either have to offer an alternative (ABIv2) or
adjust the CU price / fees and block packing limits.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We definitely need to do something like this. However, we should combine this with @igor56D's work on the cost model into a single change, so that we don't keep breaking devs. We should do a big change, make certain usage patterns significantly more expensive, have proper comms around this, and do this once.

@deanmlittle
Copy link
Contributor

Conceptually, fixing usage-based pricing makes total sense and is a good idea. Practically speaking, if the goal is to fix CPI via direct mapping, it makes no sense to try and solve for distorted computational economics of behavior that we explicitly plan to remove. If we’re going to ship DM, we should do that first, eliminate the entire nested CPI cost section and reevaluate our cost model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants