-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
Good ideas. The PoE contract addresses are set via bootstrap and are available already for clients via
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. |
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 |
This is a very old idea. Is this still relevant @daniellarita ? |
@ethanfrey what do you think, is this ticket still relevant? |
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 |
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 }
whereContractType
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.
The text was updated successfully, but these errors were encountered: