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

[Feature]: Query-Dependent Accounts Module #19912

Open
trevormil opened this issue Apr 1, 2024 · 2 comments
Open

[Feature]: Query-Dependent Accounts Module #19912

trevormil opened this issue Apr 1, 2024 · 2 comments

Comments

@trevormil
Copy link

trevormil commented Apr 1, 2024

Summary

The idea behind this proposal is a new module that acts as its own account (similar to x/group) and will have its own address, but the "account" is controlled by a fixed on-chain query declared at genesis. If the calling user satisfies the on-chain query, they are approved to execute messages from this account.

For example, this can be used to implement token-bound registries (EIP 6551). Ex: I create an "account" with the query "must own x1 of this NFT" as the criteria. Whoever meets such criteria can execute messages from that account.

It could also be used to implement name-based accounts. For example, assets will be tied with the domain name instead of the host account. Thus, when the name is transferred, all child assets are also automatically transferred.

It could also be really neat to leverage this with WASM smart contracts as well.

Problem Definition

No response

Proposed Feature

This would be its own module similar to x/authz or x/group. It could theoretically also maybe be integrated as a decision policy in x/group, but I feel like that overcomplicates things.

@hxrts
Copy link
Contributor

hxrts commented Apr 8, 2024

I like this. I think you can break it down into a couple pieces, some of which already exist:

  • an authentication scheme that allows an account to demonstrate they are indeed the holder of an NFT within some collection (or any other criteria)
  • an authorization scheme that verifies that holders of those NFTs are eligible to submit messages that meet some criteria
  • the initialization and reprogramming of the authentication + authorization logic, which itself can be done with auth/authz if they are constructed properly

@trevormil
Copy link
Author

Yea, agreed, I think that a generic solution would be best (not just specific to NFTs). For example, if the queries[] or msgs[] are as expected, I can send any Msg from the account.

But, yea, all pieces are in place.

  • Queries or Msgs for the criteria checks
  • New module accounts with their own address that can send txs (ex: x/group)

Could even be added to x/group -> only be able to vote on the decision if you meet the criteria.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: ☃️ Icebox
Development

No branches or pull requests

2 participants