Hello to the Rootstock community!
A new network upgrade proposal has been published and is now open for discussion.
The Cardamom network upgrade proposal introduces several consensus protocol improvements, including changes to transaction formats, Account Abstraction support, and enhancements to the PowPeg pegout process.
Here are the key improvements proposed for inclusion in the Cardamom upgrade:
RSKIP-378: Enforce release transaction size limit
---
rskip: 378
title: Enforce release transaction size limit
created: 06-JUL-26
author: JZ
purpose: Usa, Sec
layer: Core
complexity: 1
status: Draft
description: Adds a safety margin for the size (SegWit virtual size, following BIP 141) of the release transactions the Bridge creates (peg-outs and migrations).
---
|RSKIP |378 |
| :------------ |:-------------|
|**Title** |Enforce release transaction size limit |
|**Created** |06-JUL-26 |
|**Author** |JZ |
|**Purpose** |Usa, Sec |
|**Layer** |Core |
|**Complexity** |1 |
show original
RSKIP-455: PowPeg migration to multiple outputs
---
rskip: 455
title: PowPeg migration to multiple outputs
created: 20-NOV-24
author: MI
purpose: Usa, Sca
layer: Core
complexity: 1
status: Draft
---
# PowPeg migration to multiple outputs
## Abstract
Ensure that after a PowPeg composition change the Bridge is still able to process peg-out requests without delays. To do so, update the PowPeg composition change process so that migration transactions include multiple outputs to the new PowPeg address.
## Motivation
When a PowPeg composition change process is executed, all funds are migrated to the new PowPeg address. This is done by creating a transaction that includes up to 50 UTXOs [[1]](#references) as inputs and a single output to the new PowPeg address. This causes the Bridge to have a small number of UTXOs available after a migration, producing possible delays in processing peg-out requests.
show original
RSKIP-543: Typed Transaction Envelope
---
rskip: 543
title: Typed Transaction Envelope
description: Introduce Ethereum style transaction versioning
status: Draft
purpose: Sca, Usa
author: PDG (@patogallaiovlabs), SM (@smishraiov)
layer: Core
complexity: 2
created: 2026-01-05
---
## Abstract
This is a proposal to implement [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) style *Typed Transactions* in Rootstock. This will improve Rootstock’s compatibility with the Ethereum ecosystem and make it easier to introduce other changes such as Account Abstraction and Data Availability mechanisms for rollups. Transaction Receipts in Rootstock already include a [“type field”](https://github.com/rsksmart/rskj/pull/1984) - though this is only for JSON RPC. The main departure of our proposal from EIP-2718 is the use of a Rootstock specific namespace to ensure that there are no conflicts in the type encoding between Rootstock and Ethereum.
## Motivation
The usefulness of typed transactions is evident from their adoption in Ethereum (EIP-2718). Ethereum now has several types of transactions. Currently, in addition to legacy transactions, the other types include: type 1 for access lists (EIP-2930), type 2 for gas fee market (EIP-1559), type 3 for blob-carrying transactions intended for data availability for rollups (EIP-4844) and type 4 for a particular type of Account Abstraction (EIP-7702).
show original
RSKIP-545: Set Code for EOAs
---
rskip: 545
title: Set Code for EOAs
description: Injects code into an EOA account through a set-code transaction
status: Draft
purpose: Sca, Usa
author: PDG (@patogallaiovlabs), SM (@smishraiov), SDL (@sergiodemianlerner)
layer: Core
complexity: 3
created: 2026-01-06
---
## Abstract
This RSKIP proposes to implement [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) style Account Abstraction in Rootstock to improve user experience and smart contract wallet capabilities. This will allow Externally Owned Accounts (EOAs) to set code in their accounts in the form of delegation pointers (contract addresses) which contain the code to run in the EOA’s own context. As stated in the abstract of EIP-7702, This is done by attaching a list of authorization tuples – individually formatted as `[chain_id, address, nonce, y_parity, r, s]` – to the transaction. For each tuple, a delegation indicator `(0xef0100 || address)` is written to the authorizing account’s code. All code executing operations must load and execute the code pointed to by the delegation.
## Motivation
There have been several proposals for Account Abstraction in Ethereum and also in Rootstock ([RSKIP-167](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP167.md)). EIP-7702 was the version that finally received very strong support and has seen strong adoption since it was included in Ethereum’s Pectra upgrade. Some benefits of EIP-7702 include batched transactions, sponsored transactions, and fine grained access control and permissions for smart-contract wallets. This approach can even work with existing infrastructure and tooling for other account abstraction mechanisms, such as ERC-4337 wallets.
show original
RSKIP-546: Implement EVM’s Type 1 and Type 2 Envelope formats
---
rskip: 546
title: Implement EVM's Type 1 and Type 2 Envelope formats
created: 27-JAN-2026
author: PDG (@patogallaiovlabs), SM (@smishraiov)
purpose: Usa
layer: Core
complexity: 1
status: Draft
description:
---
## Abstract
This is a proposal to support Ethereum's Type 1 and Type 2 formatted transactions in Rootstock. Apart from the new (EIP-2718 based) encodings for transactions and receipts, this proposal does not introduce any other changes to Rootstock's consensus rules. In particular, neither "Access Lists" (EIP-2930) nor "Dynamic GasPrice" parameters (EIP-1559) will be implemented. Transactions encoded in these new formats will be executed in the same way as legacy transactions. Access Lists, if provided, will not be used in the EVM, but will result in additional gas fees as specified below. For Type 2 transactions, the lower of the two EIP-1559 gas price fields will be used as the transaction’s effective gas price.
## Motivation
At present, Rootstock only supports legacy transactions. Since the adoption of EIP-2718 in Ethereum, there are now four transaction types based on that format. In Ethereum, wallets and applications have largely migrated away from legacy transactions.
show original
RSKIP-559: Deterministic selection of the next pegout to confirm
---
rskip: 559
title: Deterministic selection of the next pegout to confirm
description: Introduce a clear rule for selecting the next pegout ready to be confirmed and signed
status: Draft
purpose: Usa
author: JT
layer: Core
complexity: 1
created: 01-SEP-26
---
# Deterministic selection of the next pegout to confirm
## Abstract
Once a pegout has acquired the required number of confirmations in Rootstock, it is ready to be
confirmed and signed by the powpeg, and the Bridge picks one of the pegouts waiting for
confirmations to move forward.
show original
RSKIP-643: New pegout registration method
---
rskip: 643
title: Registering peg-out and migration transactions by hash
created: 29-SEP-26
author: JT
purpose: Sca
layer: Core
complexity: 2
status: Draft
description: Let a peg-out or migration transaction be registered by its hash, without resubmitting the transaction the Bridge itself created
---
# Registering peg-out and migration transactions by hash
## Abstract
A peg-out or a migration transaction is registered in the Bridge so that the funds it pays back to a
federation (the change of a peg-out and the funds moved by a migration) can be spent again. Today
that is done by submitting the whole serialized transaction to `registerBtcTransaction`, which is
redundant: the Bridge built that transaction, so it already knows its outputs.
show original
RSKIP-692: Direct precompile call failure semantics
We warmly invite the Rootstock community to review the proposal, participate in the discussion, share feedback, and suggest improvements.
Your feedback is an important part of the process of shaping the future of the Rootstock protocol.
Thank you for your continued support and engagement!
2 Likes
Looking really strong. Account abstraction is a great feature to include and already heard positive comments about multiple utxos in peg-outs.
2 Likes
Excited to see this ! I am one of the coauthors of the proposals related to account abstraction. I am grateful that they are being considered for inclusion in this network upgrade. RSKIP-545 is based on EIP-7702, which has seen strong adoption on ethereum. If accepted by the rootstock community, developers will be able to use all the existent tooling for account abstraction for evm compatible chains
3 Likes
We’ve also included RSKIP-378: Enforce release transaction size limit as part of the list of proposed RSKIPs