Credit Accounts with Scheduled Transfers

Maintain credit accounts through a timestamped sequence of operations. Support account creation, credit additions, immediate transfers, balance ranking, scheduled transfers, cancellation, account merging and historical balance queries.

Operation ordering

Process queries in order. Each row contains an operation name, its timestamp and the arguments below. Before every external operation at timestamp t, process all pending transfers whose due time is at most t, ordered by due time and then scheduling order. Record a scheduled transfer's balance changes at its due time, even when the next external operation occurs later.

Return one string per external query. Use true or false for booleans, base-10 strings for numbers and an empty string for an unsuccessful numeric or identifier result.

Accounts and immediate transfers

• ["CREATE_ACCOUNT", t, id]: create an account with balance zero and return true. Return false if that identifier has ever been created, including an identifier removed by a merge.
• ["ADD_CREDIT", t, id, amount]: add positive credits to an active account and return its new balance. Return the empty string if the account is inactive or absent.
• ["TRANSFER", t, source, target, amount]: transfer positive credits between distinct active accounts. Return the source balance after success. Return the empty string if either account is absent or inactive, the identifiers are equal or funds are insufficient.
• ["TOP_K", t, k]: rank active accounts by current credit balance descending, breaking ties by identifier ascending. Return at most k entries formatted id(balance), joined by commas without spaces. Return the empty string if no active accounts exist.

Scheduled transfers

• ["SCHEDULE_TRANSFER", t, source, target, amount, delay]: if the endpoints are distinct active accounts, schedule a transfer for t + delay and return the next global identifier transferK, starting with transfer1. An invalid request returns the empty string and consumes no identifier.
• Scheduling does not reserve or move credits. When the transfer becomes due, execute it only if both endpoints remain active and the source has sufficient credits. Otherwise skip it permanently. A processed transfer is no longer pending whether it succeeds or fails.
• ["CANCEL_TRANSFER", t, source, transferId]: return true and cancel the transfer only when it is pending and belongs to that active source account. Return false otherwise. Due transfers are processed before this cancellation, including transfers due exactly at t.

Merge and balance history

• ["MERGE_ACCOUNTS", t, survivor, absorbed]: first process due transfers as usual. Return false if the identifiers are equal or either account is not active. Otherwise add the absorbed balance to the survivor, deactivate the absorbed account, cancel every remaining pending transfer having the absorbed account as either endpoint and return true. Pending transfers do not reserve funds, so cancellation does not refund credits.
• ["GET_BALANCE", t, id, timeAt]: return that identifier's balance immediately after all activity at timeAt, or after its latest earlier activity if nothing occurred exactly then. Return the empty string if the account had not been created or was already deactivated at that historical time. A deactivated identifier remains queryable for its own pre-merge history.
• The survivor keeps its own pre-merge history. Its combined balance starts at the merge timestamp. The absorbed identifier stops existing at the merge timestamp.

For this exercise, assume timestamps are strictly increasing, identifiers are never reused, transfers use positive integer credits without fees, failed scheduled transfers are not retried, and historical balances follow the identifier-specific rules above.