-
Notifications
You must be signed in to change notification settings - Fork 350
Description
This issue is for a rough proposal of a new operation/tx type, dubbed Promise Reserve. Under Promise Reserve, reserve obligations are lazily enforced.
Motivating example: create account, move assets, then merge:
Operations: [
CreateAccount {address: a, starting_balance: 0},
ChangeTrust {source: a, asset: ..., limit: 1000},
Payment { destination: a, amount: 1 },
ChangeTrust { source: b, asset: ..., amount: 0},
AccountMerge {destination: b},
]
This currently can fail because we need the reserves for account B and B's trustlines, and we need A to be set up before we can remove B. This requires us to over-collateralize the operation.
If instead we do something like:
Operations: [
PromiseReserves(1.5 XLM),
CreateAccount {address: a, starting_balance: 0},
ChangeTrust {source: a, asset: ..., limit: 1000},
Payment { destination: a, amount: 1 },
ChangeTrust { source: b, asset: ..., amount: 0},
AccountMerge {destination: b},
]
we can then check after executing all operations that the reserves were eventually covered.
This helps simplify proposals like ATP3 (sep-16).
We want this to be explicit rather than just changing existing behavior because there are situations depending on the old behavior. The old behavior can also sometimes be useful -- this is why the operation is slightly better than the transaction type, as you can be more fine grained with where and when reserve debts are opened or closed.
In terms of implementation, it should be fairly easy to make something like this backwards compatible as in effect, promisereserves is just a new type of payment that goes through always but encumbers a debt on the entire transaction.
Anyways, just opening up for discussion here for now.