Skip to content
This repository has been archived by the owner on Aug 21, 2024. It is now read-only.

Token interface and single balance update #257

Merged
merged 2 commits into from
Jan 5, 2023

Conversation

sisuresh
Copy link
Contributor

@sisuresh sisuresh commented Jan 5, 2023

Documentation updates for -

  • The recent token interface updates.
  • Single balance changes.
  • Removal of Soroban only built-in token contract.

@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

@sisuresh sisuresh merged commit 45f0ed4 into stellar-deprecated:dev Jan 5, 2023
classic account identifier vs a non-account identifier like a contract.

- Using `Identifier::Account`
- The balance must exist in a trustline or an account. This means the contract
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean trustline of an account?
Or do you mean trustline or an account (in the case of Lumen)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Account in the case of lumens. I'll update this to make it clear.

- Using `Identifier::Ed25519` or `Identifier::Contract`
- The balance and authorization state will be stored in ContractData, as
opposed to a trustline.
- These balances are stored in a 128-bit signed integer.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be worth mentioning how the 128-bit balance interops with the classic 64-bit balance?

/// unless this is called on the Stellar Asset Contract, in which case this can
/// be less due to reserves/liabilities.
fn spendable(env: soroban_sdk::Env, id: soroban_auth::Identifier) -> i128;

/// Transfer "amount" from "from" to "to.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe mention in the comment of this function "Transfers to the issuer account will burn the token, while transfers from the issuer account will mint." (what you had in the explanation)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issuer is an implementation detail of the SAC, and will not apply to any other token contracts, so I don't think that belongs here.

fn burn(
/// If "admin" is the administrator, clawback "amount" from "from". "amount" is burned.
/// Emit event with topics = ["clawback", from: Identifier, to: Identifier], data = [amount: i128]
fn clawback(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably good to specify some minimal set of failure conditions. E.g. if the "admin" is not the administrator, and its expected behavior (returning error code or trapping).
This applies to most of the interface functions below.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created an issue for this

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants