yuge yuge week. there is a plan for the proposals for 1) The Burn SIMD, aka The Resource Fee SIMD 2) The Disinflation SIMD to go live this week for voting. for these changes to make it into the protocol and into agave/fd we need 1) proposals to swiftly get support from 15% stake, which will make the proposal go to a vote 2) the cluster to vote yes. note that stakers will be able to vote this time around instead of relying on validators to vote on their behalf (validators can still specify default vote). 3) implementations to be reviewed and merged contact your local validator and core dev asap, and get your stake withdraw authority keys ready. The Cavey Cool validator will be supporting and voting yes on both proposals : D

The Flippening Part 1!!! during US hours, solana nonvote traffic > solana vote traffic not yet true for daily average, as there is lower traffic at night which brings the average down

this is an insane development when Kevin F Bowers first demonstrated 1.2M TPS transaction ingestion at Breakpoint 2022, seventy two (72) verify tiles were used to handle the incoming traffic fast forward four years to now, with the improvements the Mithril team has found during their client development work, 1M TPS ingestion can be done on ~8 verify tiles. this, in my opinion, eliminates the need to consider FPGA sigverify. i am currently working on getting these improvements upstreamed in agave and firedancer's respective crypto libraries as soon as possible.

many people are calling for a hyperliquid type fee-on-volume. here is why it is not needed and why The Burn SIMD is sufficient imo. i believe average swap size per txn will probably go up a bit but not much over the course of the next few years if the onchain market thesis plays out. we may get huge blocks from institutions, but we will also get a lot more retail flow and the mean order size will be roughly the same order of magnitude. as such, taking 1 bp per swap now is going to be roughly the same as taking 1 bp per swap in a few years (on average). due to some optimizations, i believe compute resources per swap will go down a bit but not much over the course of the next few years. as such, resource fees per swap now is going to be roughly the same as in a few years. if you also believe these two statements, then you believe that resource fees per swap and bps per swap will be fairly correlated (and both go up with increased volume). given this correlation, it's best to just do resource fee for two reasons: 1) it reduces protocol and toll complexity. resource fee is already destined to be implemented and deployed, and taking fee on volume is INCREDIBLY messy and invasive on apps. 2) it naturally (and softly) incentivizes larger orders, which is a form of "vip" discount AND a form of IBRL

SIMD-553 (The Burn SIMD™️): 1) addresses key tokenomics issues by giving SOL direct exposure to the demand of onchain compute 2) disincentivizes onchain slop, aligning app developer incentives with those of core developers. Core devs can and will deliver the world's fastest smart contract platform, but the vision of global onchain markets can only become a reality if the apps also acceleribrltardio 3) is coming at nearly the same time as V1 Transaction, which will give apps/users the ability (and incentive) to request the right amount of each and every resource in the txn header at no additional cost

got bored last week during accelerate while y'all were at e11even, so I worked on a limited-lookback (1 month) historical account state service: ​ getTransactionFixture(signature) -> TransactionFixture ​ which returns everything you need (pre/post accounts, feature set, sysvars, txn status, rpc client version/hash, etc) to re-execute the transaction. very helpful for debugging and trying out changes. i think main use cases are something along the lines of: ​ 1. how would this trade have gone (as a maker or a taker) if program commit B was deployed instead of A? 2. how many cus would this txn have used if some other commit was live? 3. what was the pre/post execution state of some account? why was some special branch hit? ​ in fact, 2. is exactly what i show in Figure 1 to compare p-token vs current tokenkeg. I took a random swap that went through zerofi and goonfi with my nifty client... ​ the left shows all results matching (successful replay). the right shows me adding the flag --replace-program=TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA: which replaces the current token program with the p-token program. we get a match in status, but a mismatch in CUs (and logs... p-token does not log "Instruction: Transfer"!). ​ we will be using this internally (it has already come in handy bigly twice), but we also want to try to offer this to external users. if there's enough interest we may do a pilot. dm me if you want to try it.

in light of recent events, chief puppeteer @0x_febo and I wrote a solana program and a library that allow applications to BAN the use of durable nonces within their program there are two options for you to use: 1. you can use the ensure_never_nonce function from the p-never-nonce crate that we just published within your program 2. you can cpi into the p-never-nonce program that will be deployed shortly