# Release v5.15.0 **URL:** \ **Category:** Astar\ **Created:** [July 26, 2023, 1:09pm UTC](https://forum.astar.network/t/release-v5-15-0/4890 "2023-07-26T13:09:57Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Dino](https://avatars.discourse-cdn.com/v4/letter/d/e95f7d/32.png) [@Dino](https://forum.astar.network/u/Dino)\ **Post date:** [July 26, 2023, 1:09pm UTC](https://forum.astar.network/t/release-v5-15-0/4890/1 "2023-07-26T13:09:57Z")
Hello everyone, we will share a few pieces of info for the upcoming `v5.15.0` release that is bound tomorrow, on **27th of July, 2023**. We decided to do this since it brings quite a bit of changes for the node operators, dApp users & developers, and regular users. # 1. Breaking CLI Change (Client) Some of the `WS` params that have been kept for backwards compatibility have been either completely removed or renamed ([PR](https://github.com/paritytech/substrate/pull/13384)). Both `HTTP` and `WS` server have been behind a single port for quite some time now, and this is just a cleanup of legacy parameters. The default port, `9944`, services both `WS` and `HTTP` requests. Node operators should make sure to adjust their scripts for starting the node. Please refer to the linked PR or the refreshed Astar documentation (will be merged on the 27th of July). # 2. Remote XCM Account Derivation Update (Builders) When sending a `Transact` message from one chain to another, the `message origin` on the destination chain will be different than the one on the origin chain. E.g. if **Alice** sends an XCM sequence containing `Transact` from some parachain to `Shiden`, the instruction will be executed as if **Alice\_derived** executed it. This isn’t new and has been supported on Shibuya for quite some time. The update is in how these derived addresses are calculated. Previous approach wasn’t stable, and as a result, when XCM v3 came out it changed the derived address. This isn’t good since users need to be able to rely that the derived address will remain the same. This [PR](https://github.com/paritytech/polkadot/pull/7329) introduced a more stable & configurable way of calculating derived addresses. It’s been integrated into **Shibuya** and **Shiden** for now. **Shibuya** supported the legacy, not-stable, approach so this is heads up to all developers utilizing this feature - the derived address will change after the next runtime upgrade. **Shiden** hasn’t had this feature enabled before, so there are no breaking changes, only a new feature. For those who use `xcm-tools` binary, it has also received an update to cover the new account derivation scheme. Astar docs will be updated with explanation about how these addresses are derived & how to use the new `xcm-tools`. # 3. Ethereum Transaction Accounting For PoV Size (Everyone) This is a big & important update since it brings a new dimension to how EVM gas is calculated. To give a brief introduction: - each block is a finite resource, and we can only put so many transactions into them - block is bound by two dimensions: - `ref_time` - execution time; how long does it take to execute the whole block on a CPU - `PoV_size` - how much data has to be sent to Polkadot validators to validate the block - so far, Ethereum only accounted for `ref_time`, which gets converted into gas - this is problematic since if an Ethereum transaction consumes 1% of available `ref_time` and 50% of available `pov_size`, it will only pay for the 1% - the new change will take a look at both resources, and charge the one that was consumed more - using the above example, it would mean user pays for the 50% of the consumed block capacity, instead of 1% Support for this has been added in `frontier` via this [PR](https://github.com/paritytech/frontier/pull/1039). ## How Does This Impact Me? There are 3 possible scenarios which can happen after the upgrade. 1. Gas remains same as before (some deviations possible since we’re also switching over to Shanghai configuration) 2. Gas increases because transaction consumes more `PoV_size` resource than `ref_time` 3. Transaction is no longer possible because it exceeds maximum allowed PoV size. The third scenario is extremely unlikely, but not impossible. However, it should have been impossible for such transaction to even work in the past since block containing such transaction couldn’t be validated by the relay chain. If developers are worried about such scenario, they are encouraged to try their smart contracts on **Shibuya** where the runtime upgrade will be applied first. Maximum PoV size for a transaction is ~ **3.75 MB**. This limit is imposed by the relaychain (Polkadot & Kusama) and therefore must be respected. # 4. Reserve Balance & Existential Deposit Reserve balance will no longer contribute to the existential deposit (ED). Assuming ED is greater than zero, this simply means there cannot be an account whose balance is fully reserved, without any _free balance_. We don’t expect this to impact anyone but it’s a change worth noting. # Release As usual, you can find all releases on the Github page [here](https://github.com/AstarNetwork/Astar/releases). Astar docs update [PR](https://github.com/AstarNetwork/astar-docs/pull/391) will be merged after release has been made.