Model a Consolidation Transaction for Inclusion to OCF

[Victor Mimo]

Discussed in #444

^{Originally posted by victormimo August 7, 2023}
Let's assume the scenario below.

Let's also assume the issuance objects for Bob are the same outside of quantity.

I understand that if Bob wants to transfer Alice 1100 shares, then we need to create 2 separate transfers (because transfers only have one security_id field corresponding to Bobs). One for 1000 shares and one for 100 shares, this also means that Alice will have two new Issuance events, one for 1000 and one for 100.

am I right on this logic?

Could there be a way to unify Alice's position into one for 1100 shares?

If we take a scenario where an issuer issues 1,000,000 shares to a stakeholder, it's likely that a new buyer purchases less than a million shares. This means overtime that issuance of a million shares will result in many smaller issuances since there's no way to unify positions on transfers. Even if someone buys one million shares for the exact stock_class_id, they will have to carry however many issuance objects there were to sum to a million.

One potential solution could be to change the transfer's security_id field to be an array, like resulting_security_ids
Something like.

{
      "object_type": "TX_STOCK_TRANSFER",
      "id": "bob-transfer-to-alice",
      "security_ids": ["bob-stock-1", "bob-stock-2"],
      "date": "2023-02-01",
      "resulting_security_ids": [
        "alice-stock-1"
      ],
      "quantity": "1100"
}

Let me know if I'm missing something

[Victor Mimo]

Wanted to follow up here since this is relevant to us from a gas savings perspective of writing to a blockchain. @JSv4 when we meet over zoom you proposed a work around using issuances I believe. Would you be able to provide a simple example of how that would look?

Much appreciated!

[JSIV]

Hey @victormimo, I believe we discussed this live at some point on a call before the last summit on how you could do this. You could transfer the split issuances to a new, consolidated issuance. There may be other implications to worry about there, but that should work. I'm going to close this for now, but please re-open if you have more questions / thoughts.

[Victor Mimo]

Perfect, thank you.

[JSIV]

Notes from the TWG:

• You could use a number of transfers to merge smaller issuances into larger issuances.
• Open question was re-issuance vs transfer here. Do you have to (or are there situations where you have) use a re-issuance vs a transfer.
  • Need more clarity on description of transfer.
  • Some examples
    • Single certificate based on 13 separate exercise events being combined in a single certificate.
  • Some proposals
    • Use multiple transactions
    • Create a new consolidation transaction
    • Use a re-issuance potentially.
  • Open questions for LFWG
    • Given the three proposals, is there an ironclad "right" approach? If not, what's the desired convention?

[jarrettq]

Additional examples where we have encountered other real world many-to-one security scenarios (where we have the documents and stock certs as data points to run off of):

1. Multiple stockholders participating in a secondary sale to a single purchaser, which all consolidate in a single resulting security and multiple balance securities (~one per seller).
2. Multiple holdings for a single stockholder in one share class that are converted to another share class, and consolidated to a single certificate in the process.
3. Multiple option exercises being consolidated to a single stock certificate.

[JSIV]

Further discussion on this point - we do need something to consolidate transactions as the only way to do this ATM is to cancel and re-issue, which breaks any structured link between the securities.

Also, as flagged by @arthur-clara, this transaction type will simplify and clarify the validation work. Some of the proposed rules for resulting_security_id and balance_security_id fields in Arthur's proposal rely on a Transfer always have the resulting_security_id point to an issuance with a new stakeholder_id.