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

use Ownables for LCA/ICA transfer #9087

Open
turadg opened this issue Mar 13, 2024 · 1 comment
Open

use Ownables for LCA/ICA transfer #9087

turadg opened this issue Mar 13, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@turadg
Copy link
Member

turadg commented Mar 13, 2024

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

@turadg turadg added the enhancement New feature or request label Mar 13, 2024
@turadg turadg self-assigned this May 20, 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? -->
@turadg
Copy link
Member Author

turadg commented May 29, 2024

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 makeTransfer method that revokes its access to the underlying account.

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
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant