Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promise Reserve Operation/Transaction Type #284

Open
JeremyRubin opened this issue Apr 9, 2019 · 0 comments
Open

Promise Reserve Operation/Transaction Type #284

JeremyRubin opened this issue Apr 9, 2019 · 0 comments
Labels
CAP Represents an issue that requires a CAP. enhancement CAP that adds or changes functionality as opposed to a fix. needs draft This an issue that has no corresponding draft, and as such has not entered the CAP/SEP process.

Comments

@JeremyRubin
Copy link
Contributor

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.

@theaeolianmachine theaeolianmachine added CAP Represents an issue that requires a CAP. enhancement CAP that adds or changes functionality as opposed to a fix. help wanted Open especially for those who want to write a CAP/SEP! needs draft This an issue that has no corresponding draft, and as such has not entered the CAP/SEP process. and removed help wanted Open especially for those who want to write a CAP/SEP! labels Apr 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CAP Represents an issue that requires a CAP. enhancement CAP that adds or changes functionality as opposed to a fix. needs draft This an issue that has no corresponding draft, and as such has not entered the CAP/SEP process.
Projects
None yet
Development

No branches or pull requests

3 participants
@theaeolianmachine @JeremyRubin and others