You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently, custodian capabilities and underwriter capabilities can become a contended resource if they are used in multiple contexts.
Hence a binding schema is proposed, whereby a capability contains a field(s) describing the context in which it should be used.
Also proposed is a "duplicate_cap()" function, which creates a new unbound capability instance from a bound capability, for example so that multiple accounts can be presided over by the same custodian without transaction collisions.
The text was updated successfully, but these errors were encountered:
Presently, custodian capabilities and underwriter capabilities can become a contended resource if they are used in multiple contexts.
Hence a binding schema is proposed, whereby a capability contains a field(s) describing the context in which it should be used.
Also proposed is a "duplicate_cap()" function, which creates a new unbound capability instance from a bound capability, for example so that multiple accounts can be presided over by the same custodian without transaction collisions.
The text was updated successfully, but these errors were encountered: