Action required: check for ExecutedTransfer contracts and upgrade to Registry v0.14.2

Wallet operators,

Registry versions prior to 0.14 were creating ExecutedTransfer contracts. These create many so-called stakeholder groups, which may cause issues with the ACS commitment processor, it holds data in memory per stakeholder group. To prevent your node requiring too much RAM and eventually becoming unusable, you need to act now. A fix is in progress for 3.7, ETA November 2026.

1. Check how bad the problem is

Run this on your participant node, against the indexer or sync service tables, to count active contracts per template:

with ordered_changes(contract_id, change, row_num)
         as (select contract_id,
                    change,
                    ROW_NUMBER()
                    OVER (partition by contract_id order by ts desc, repair_counter desc, change asc)
             from par_active_contracts)
select c.template_id, count(*) as n_active
from ordered_changes o
         join
     par_contracts c
     on c.contract_id = o.contract_id
where o.row_num = 1
  and o.change = 'activation'
group by c.template_id
order by n_active desc;

(Assumes no re-assignments.)

If you see ExecutedTransfer in the order of millions, then you have a problem and you should contact us for help.

2. Upgrade to v0.14.2 to stop leaking more contracts

Target release dates:

• DevNet / TestNet: Thursday 3 September
• MainNet: Wednesday 10 September

3. Upgrading stops the growth but does not remove existing contracts

Contracts already in your ACS stay there until they are archived. If your counts are high, contact us before you start.

4. If your integration depends on these models

Unlikely, but if you do, the migration guide is here: Transaction History Parsing - DA Apps

Questions? reply here or reach out to your usual contact