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
// PartyType are the different roles parties on a contract may useenumPartyType {
// PARTY_TYPE_UNSPECIFIED is an error conditionPARTY_TYPE_UNSPECIFIED=0;
// PARTY_TYPE_ORIGINATOR is an asset originatorPARTY_TYPE_ORIGINATOR=1;
// PARTY_TYPE_SERVICER provides debt servicing functionsPARTY_TYPE_SERVICER=2;
// PARTY_TYPE_INVESTOR is a generic investorPARTY_TYPE_INVESTOR=3;
// PARTY_TYPE_CUSTODIAN is an entity that provides custodian services for assetsPARTY_TYPE_CUSTODIAN=4;
// PARTY_TYPE_OWNER indicates this party is an owner of the itemPARTY_TYPE_OWNER=5;
// PARTY_TYPE_AFFILIATE is a party with an affiliate agreementPARTY_TYPE_AFFILIATE=6;
// PARTY_TYPE_OMNIBUS is a special type of party that controls an omnibus bank accountPARTY_TYPE_OMNIBUS=7;
// PARTY_TYPE_PROVENANCE is used to indicate this party represents the blockchain or a smart contract actionPARTY_TYPE_PROVENANCE=8;
// PARTY_TYPE_CONTROLLER is an entity which controls a specific asset on chain (ie enote)PARTY_TYPE_CONTROLLER=10;
// PARTY_TYPE_VALIDATOR is an entity which validates given assets on chainPARTY_TYPE_VALIDATOR=11;
}
The party type is currently an enum. This is inflexible because anything that would deviate from this list cannot be used without a protocol change and release. Also, this list is generic, but was likely made with Figure's origination and servicing flow in mind.
Proposal
Given there's benefits to using an enum and also possibly not wanting to migrate from an enum to string type, I'm proposing the addition of the following types. These types would allow the caller to illustrate arbitrary parties on sessions without having to fit into the concrete party types that are already defined. This would be up to the caller, but including a description of the usage of these party types would be great inside of the scope specification.
// PartyType are the different roles parties on a contract may useenumPartyType {
...
PARTY_TYPE_GENERIC_1=12;
PARTY_TYPE_GENERIC_2=13;
PARTY_TYPE_GENERIC_3=14;
PARTY_TYPE_GENERIC_4=15;
PARTY_TYPE_GENERIC_5=16;
PARTY_TYPE_GENERIC_6=17;
}
For Admin Use
Not duplicate issue
Appropriate labels applied
Appropriate contributors tagged
Contributor assigned/self-assigned
The text was updated successfully, but these errors were encountered:
It would be nice to get a batch of these to add ... perhaps some that make sense for Infineo and their insurance use case and include those with this update as well... having a large list of types isn't the worst thing in the word.
Summary
Allow more arbitrary party types.
Problem Definition
The party type is currently an enum. This is inflexible because anything that would deviate from this list cannot be used without a protocol change and release. Also, this list is generic, but was likely made with Figure's origination and servicing flow in mind.
Proposal
Given there's benefits to using an enum and also possibly not wanting to migrate from an enum to string type, I'm proposing the addition of the following types. These types would allow the caller to illustrate arbitrary parties on sessions without having to fit into the concrete party types that are already defined. This would be up to the caller, but including a description of the usage of these party types would be great inside of the scope specification.
For Admin Use
The text was updated successfully, but these errors were encountered: