This section contains important information to be aware of when using Existing Account Simulation:

Accounts must be already open before simulation start time. Existing Account simulation does not support pending accounts.

Existing Account Plan Supervision is currently not supported. That is, specifying an existing Account ID will not also resolve its existing supervision associations and plan. This may lead to an incorrect simulation as a result. -If an account has been converted to a new version since the simulation start time, the accuracy of the results depends on the differences in behaviour between the contract versions (including their schedules), because the simulation will use the current version of the product.

Accounts with schedule statuses other than SCHEDULE_STATUS_ENABLED can be simulated, however the status of the tag throughout the simulation is not considered: the simulation will always behave as if the Account Schedule Tag is in an ACCOUNT_SCHEDULE_TAG_SCHEDULE_STATUS_OVERRIDE_NO_OVERRIDE state.

Accounts with an Account Schedule Tag are not supported. Any existing schedules connected to the tag as of simulation start time may have incorrect simulated jobs generated as a result.

The amount of existing data to fetch for a particular account is determined by the superset of all hook requirements in the corresponding product. If an existing account has a lot of data associated, and large requirement periods within their contract (for example, fetching >1k postings due to a 1+ year requirement period in a Smart Contract hook), the simulation may take a long time to complete.

Backdated postings (as described in The Balance Resource) are only supported so long as both the value timestamp and insertion timestamp of the posting are before simulation start time. If an unbalanced backdated posting is detected an error will be reported to the user. To resolve this, the simulation start time should be modified to be either before or after both Value timestamp and Insertion timestamp of the affected posting.

Existing Account Simulations with start timestamps too far in the past (that is, to a previous major Vault Core version) may not behave as expected.

Live requirements may behave differently due to the state of the account being pinned to the simulation start time. For example, running a derived parameter hook as of an effective time in the past using live requirements will not return the same value as running a existing account simulation with a start timestamp in the past, and a derived parameter output with the same timestamp. This is due to the real Vault having a system time of the current time, but the simulated Vault having a system time of simulation start time.