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

Add a function to the token contract to get the admin #541

Closed
leighmcculloch opened this issue Oct 18, 2022 · 5 comments
Closed

Add a function to the token contract to get the admin #541

leighmcculloch opened this issue Oct 18, 2022 · 5 comments

Comments

@leighmcculloch
Copy link
Member

I propose we add a function to the token contract that returns the admin.

There's no way from outside the token contract to introspect who the admin is. This seems like trivial thing to add. The contract already exposes other details about itself.

The use case is for contracts who wish to check if a participant in their invocations has any special capabilities for the token contract.

Another use case is for general ability for dapps and other tools to ask a contract who its admin is, without having to introspect actual contract data which we decided early on to avoid doing and to learn into providing read functions.

@willemneal
Copy link
Member

willemneal commented Oct 18, 2022

Is admin the same as owner in this context?

@leighmcculloch
Copy link
Member Author

It is. It is essentially the same concept as an "issuer" on Stellar today, although it can be more than a Stellar account as it can also be another contract or an ed25519 key independent of any account.

@leighmcculloch
Copy link
Member Author

This seems like trivial thing to add.

I overlooked one aspect that does make this a little less trivial to implement: the Native token contract deployment has no admin. The function probably shouldn't 💥 when called on the native contract.

@leighmcculloch
Copy link
Member Author

The admin function could return Option<Identifier>, but then its utility seems less useful if it can sometimes not be set. This seems less useful if it doesn't always have a value, and could be the cause of a contract being brittle. I'm leaning towards closing this as 'not planned' unless anyone can see a need.

(I had a specific use, but that use has evaporated for unrelated reasons.)

@sisuresh
Copy link
Contributor

sisuresh commented Jun 2, 2023

Duplicate of #635

@sisuresh sisuresh marked this as a duplicate of #635 Jun 2, 2023
@sisuresh sisuresh closed this as completed Jun 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants