-
Notifications
You must be signed in to change notification settings - Fork 212
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
use Ownables for LCA/ICA transfer #9087
Labels
enhancement
New feature or request
Comments
This was referenced May 23, 2024
mergify bot
added a commit
that referenced
this issue
May 28, 2024
refs: #9087 ## Description While getting started on #9087 I thought it would be helpful to have less boilerplate in tests. ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
Dropping priority because we don't need this for release. We can retrofit later by upgrading the holder object (with the invitationMakers etc) with a |
mergify bot
added a commit
that referenced
this issue
May 30, 2024
refs: #9087 stacked on: #9415 ## Description Ownabality/tradability of LCA/ICA accounts (#9087) is not a requirement for the next release. When it is needed, we can retrofit with Exo class upgrades. This PR removes the stubs so they don't appear to be needing implementation. It also has a bunch of other cleanup done in the course of exploring. ### Security Considerations Takes away a hypothetical authority. ### Scaling Considerations none ### Documentation Considerations Adds some new documentation on the Exo relationship. That could get stale but I think it's worth having. ### Testing Considerations CI ### Upgrade Considerations Not yet deployed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
#9075 and other Orchestration invitations need to provide ownable objects (aka "use objects") so that they can be transferred and revoked.
VaultFactory has a vaultHolder exo for this. We now have
prepareOwnable
but it hasn't been battled tested.Description of the Design
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: