Transaction timeouts create delay tasks for the run loop that persist for the entire duration of the timeout, regardless of whether the transaction that created them has been destroyed. This could potentially be a concern in cases where the timeout is set to be very long.

I haven't done a full accounting of the memory, though I think that there are 128 bytes used in 64-byte fast allocated chunks plus some other memory that's not being fast allocated.