Hey @Chicken_Chief, totally valid questions. Give us a few days to consolidate the relevant information and then we’ll either publish an article or write the answers below.
When we release new contract versions, we typically “let them cook” for at least 6 months under our bug bounty programs to give security researchers plenty of time to find and disclose new vulnerabilities that may have been introduced. The contracts themselves are production-ready and audited, but we like to be extra safe before we start pushing them out to all our users.
I will let @chris_Safe give you a full answer to “what is new”, but in the meantime, you can take a look at the changelog in the contract repository for a more detailed list. What is worth higlighting in my opinion is:
We refactored some code so that the account can be used with ERC-4337 (the account abstraction ERC). This would allow you to attach the 4337 module and use any 4337 bundler for relaying Safe transactions. Prior to this version, we were doing something that violated the 4337 signature validation rules (specifically around the GAS opcode in case you are interested).
ERC-165 check on new guards. This means that when adding a guard a new check was added that ensures that the contract you are attaching as a guard actually supports the Safe transaction guard interface. This helps prevent setting the guard to a contract that doesn’t support being one and bricking your account.
Fixed an issue with the ERC-1271 (smart contract signatures) implementation in the compatibility fallback handler. In particular, it works better now with nested Safes.
I recognize that you wanted answers ”explaining beyond an EIP number”, and each of my answers have an EIP number in them ( sorry!). Hope the additional explanation helps though.
Thanks for explaining the process. So it’s not that v1.5.0 won’t be accessible through an existing Safe upgrade|migration, it’s that it needs to be tested before upgrading is enabled.
Answering for @chris_Safe here specifically with reference to Safe**{Wallet}**.
The Wallet works and will continue to do so in the same way for versions 1.3.0 and upwards, with the caveat being that you should have the correct L2 contract if you are using one.
If there comes a point that there are features that are not available to 1.3.0. then you will still be able to use the wallet just those specific features won’t be available.
I wouldn’t envisage any version specific features arriving in the next 6 months.
In terms of migrating and delegate calls verify:
You’re calling the official Safe singleton addresses
Use the official migration contracts provided by Safe team
That the upgrade transaction should be a delegate call to the migration contract
You can find all contracts at Smart Account Supported Networks – Safe Docs , in addition if you are technically inclined you can find a lot more detailed information on our developer docs linked there, including th EIP related information. This will also show information around Guards and Modules both of which have seen improvements in the upgrade to 1.4.1. and now to 1.5.0 the majority of these changes for now, will have to be taken advantage of using the SDK
In terms of what’s new and how they impact wallet the main improvements are around nested safe’s as Nick mentioned above, many of these enable better nested safe functionality in the UI, something added relatively recently.
In short we recommend to use the latest version with the wallet it leads to better performance and future proofs it.
For the majority of use cases you don’t have to upgrade, it is difficult to ascertain this without knowing your specific use case. I wouldn’t see any downside to upgrading. If there were to be a situation where older safe versions would lead to any breaking changes we would telegraph this well ahead of time.
sorry!). Hope the additional explanation helps though.