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

Expose contract registry to other contracts #129

Open
ethanfrey opened this issue Sep 9, 2021 · 5 comments
Open

Expose contract registry to other contracts #129

ethanfrey opened this issue Sep 9, 2021 · 5 comments
Assignees
Labels
Requires Information Requires more information. Specify from whom! revisit_priority can be done later

Comments

@ethanfrey
Copy link
Member

An improvement idea I had - please give feedback, so we can refine:

We are producing a number of unique and important contracts - staking, engagement, validators, etc. this will only grow with the oversight committee.

So far, the only way another contract can reliably interact with them is if we produce custom message types to call them. Or some adaptor layer between the current staking API. It would be nice to allow direct contract-contract calls.

My thought to enable this is to have a new TgradeQuery variant like Contract{ kind: ContractType } where ContractType is an enum of all the standard contracts we install in poe (or elsewhere on startup of the chain).

When thinking this, I realised some canonical registry would also have some other uses, like one listing all "official" tokens on the chain, providing a unique mapping of ticker symbol (EUR) to a cw20 contract address.

Such registries would be useful both for other contracts as well as for frontend clients.

@alpe
Copy link
Contributor

alpe commented Sep 10, 2021

Good ideas. The PoE contract addresses are set via bootstrap and are available already for clients via

tgrade q poe  contract-address        -    Show contract address for given contract type

Adding a custom query handler for contracts would be very easy.

The contract registry though is a bigger story. We need to define how contract addresses can be added/ updated/ removed and what other meta data may be required for clients.

If we restrict this to the oversight committee then the data can be trusted but the process may be very slow and complicated.
If we let everybody add and manage their contracts then we have to fight all kind of fraud that comes with this.
In both cases I think this can be implemented as contract and may evolve naturally if we don't start this ourselfs. So it would be good to prepare something.

@ethanfrey
Copy link
Member Author

I guess defining a query api and adding a "token registry" address is the first registry I propose may be a "good enough" solution for my token idea.

I agree, this part needs a lot more thinking and refinement

@alpe alpe added the good first issue Good for newcomers label Nov 19, 2021
@alpe alpe removed the good first issue Good for newcomers label Nov 19, 2021
@alpe alpe added the revisit_priority can be done later label May 10, 2022
@alpe alpe added this to the Tgrade - "Post Mainnet" milestone May 10, 2022
@alpe alpe added the Requires Information Requires more information. Specify from whom! label Jul 7, 2022
@alpe
Copy link
Contributor

alpe commented Jul 7, 2022

This is a very old idea. Is this still relevant @daniellarita ?

@daniellarita daniellarita self-assigned this Jul 7, 2022
@daniellarita
Copy link

@ethanfrey what do you think, is this ticket still relevant?

@ethanfrey
Copy link
Member Author

I think custom query handler could be very good addition for tgrade, especially if people want to use multisig contracts to handle their staking or such. I would support adding that for 1st tgrade upgrade (or 2nd).

The general question on contract registry is a need/request for many wasmd chains and a very hard design space. Someone could launch their own project just on this theme.

Let's reflect on how to support this without doing it all. But a custom query just for poe contracts makes sense

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Requires Information Requires more information. Specify from whom! revisit_priority can be done later
Projects
None yet
Development

No branches or pull requests

3 participants