Transfers when the quantity is spread over multiple security_ids

[victormimo]

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

[victormimo]

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!

[jarrettq]

Not an OCTC member, so take this as an interpretation rather than fact, but my understanding is that from the perspective of securities law it becomes important to maintain an unambiguous record of the origins for any given set of shares.

This mainly comes into play when tracking compliance items like the Rule 144 date - the original security for 1,000 shares may have one date while the 100 has another, based on the original date of issuance for the underlying shares.

That, combined with the need to remove any potential ambiguity in a scenario where, for example, Bob's original issuances were for 800 and 500 respectively, means capturing which amounts were withdrawn from which securities becomes tricky when looking to reduce the number of resulting securities involved.

[victormimo]

hi @jarrettq, I don't believe my solution would lead to ambiguity since the multiple security_ids would track the origin securities. But I've been mostly referencing basic issuances. Where all the underlying security ids have large overlap on fields.

we take a complex issuance object, such as

    "object_type": "TX_STOCK_ISSUANCE",
    "id": "7e57d004-2b97-44e7-8f31-8104c6130200",
    "security_id": "551ca255-12ec-4a5d-9cb0-9e12f6d1f25c",
    "date": "2022-08-23",
    "security_law_exemptions": [],
    "stakeholder_id": "aceb81e6-2d19-4ef2-ac53-05ff210d3508",
    "custom_id": "PA-2",
    "stock_class_id": "8f14e45f-ea0c-495d-88fd-c6476d68b4b7",
    "share_price": {
        "amount": "0.0001000000",
        "currency": "USD"
    },
    "quantity": "4000000",
    "cost_basis": {
        "amount": "0.0001000000",
        "currency": "USD"
    },
    "stock_legend_ids": [
        "f04e7c40-0a64-4d2e-9208-8828098d73d5"
    ]
   }

and try to do a transfer where multiple securities differ in say cost_basis, stock_legend_ids, and security_law_exemptions, then I agree we lose that info and bring ambiguity.

At the last OCF technical call, we discussed the potential for many transfers leading to one issuance (again, as long as the overlap in those is high), I've yet to test this as an MVP.