Asset Splits CAP Working Group

[John Wooten]

Hi all,

In search of working group participants/consultants for CAP implementing forward and reverse stock split ops (discussion thread, PR link). 

Chiefly in search for SDK devs/downstream systems developers

This issue makes a huge difference for securities registrars building on Stellar, and moving forward with the CAP would open up traditionally-opaque financial products directly to billions traditionally disenfranchised from equity ownership. (that means a lot of new Lumen holders)

Any partakers would be much obliged

- John 

[John Wooten]

Notice, for instance, that DSTOQ's ADR Apple shares (link) don't reflect the recent 4:1 forward split, which very easily creates investor confusion (and messes up direct dividends or cash in lieu of dividends)

[Markus Paulson-Luna]

Not sure a CAP is necessary for this. I believe it's achievable utilizing clawbacks and payments. For instance, in a case of a 4:1 split DSTOQ could clawback all shares and return 4 shares to the accounts shares were clawed back from, (clawback before payment is necessary to avoid any issues with atomicity). In the case of a 1:4 split they could clawback 4 shares and return 1. 

[John Wooten]

See https://groups.google.com/g/stellar-dev/c/40u3UiqMXk0

From protocol principles: there should be only one obvious way to do things on Stellar. 

This manual implementation is slow, tedious, and congestive... plus it requires asset issuers to have clawback or other parameters enabled, which doesn't hold for all assets.

Furthermore, implementations can be extremely error-prone for large amounts of trustlines which all much freeze during the split, including revoking outstanding DEX offers to account for the new split ratio.

One txn op to execute a split solves all these challenges and removes the chance for issuers to make clerical mistakes, either technical or fat-fingered. 

[John Wooten]

This logic namely fails for issuers who have preexisting trustlines without clawback enabled. Thus, they can't fully execute a split, irregardless of the capital illiquidity and confusion created by manual iterations.

We'll start work on the CAP internally next week without SDK/downstream devs per CAP recommendations with the caveat that we made every best effort to procure community aid.

- John 

On Monday, September 27, 2021 at 4:11:13 PM UTC-4 Markus Paulson-Luna wrote:

[Nicolas Barry]

I think the challenge with a CAP approach is that you're going to have to figure out things like:

* how to implement this in a scalable way - you can't just have a single operation trigger millions of changes on the ledger (trustlines, offers, claimable balances need to be updated)

* how to handle the various edge cases - things like overflowing int64 in trustlines, offers etc

* what to do about smart contracts (like payment channels) that expect a certain state on chain

* do you want to support reverse splits? They come with other problems (like how to do rounding)

There might be some interesting ways to solve this, I guess only one way to find out :)

My intuition is also that this is not really doable 100% at the protocol layer, and instead you just need to standardize on how to do this with a SEP + potentially some other CAP that helps in this situation (so you end up with a hybrid solution).

Nicolas

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/ac5c9a77-4955-455b-b6bc-aab78cc89a06n%40googlegroups.com.

[John Wooten]

For instance, there are many examples of transfer agents executing 10:1 forward splits... but only for company insiders.

That's bad

[John Wooten]

I'm with you there... There are some nuances like roundoff that we'll have to accept with the caveat that, in standard use cases,  issuers very rarely execute a split (say once or twice a decade)

Started as a SEP, but saw a CAP as the best way to actually relevant txn op. 

To your point of SEP+CAP, one option could be a manual split SEP standard—which again really does introduce a lot of failure vectors not least of which is central accounting trust [we don't like that] 

+ a CAP that freezes all trustlines / cancels all offers for an issue

(this doesn't fix the CLAWBACK_REQUIRED challenge)

Main objectives are to minimize time spent with untradeable assets (capital illiquidity sucks, and transfers by law must execute timely) 

& ensure correctness

As for smart contracts are you referencing Turrets or just claimable balances (which ought be low in practice)?

John

On Tuesday, September 28, 2021 at 8:03:57 PM UTC-4 Nicolas Barry wrote:

[Nicolas Barry]

> As for smart contracts are you referencing Turrets or just claimable balances (which ought be low in practice)?

Protocols that use pre-signed transactions.

A simple example relevant to your use case is a set of transactions that represent vesting X shares over a 5 years. This can just be done as pre-signed transactions with timebounds that transfer X/5 every year from an escrow account (that can only be unlocked by a different presigned transaction).

All transactions are known in advance.

Nicolas

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/d2575777-ef8e-4ccc-8806-6bbfb9079d54n%40googlegroups.com.

[John F. Wooten, IV]

Usually you handle vesting offline (you need employer/attorney statements releasing the shares, annual check-ups with mangmgnt, and other nuances that keep restricted shares separate from outstanding shares)

Executing vesting based on pre-signed txns presents a lot of seemingly-minor attack vectors that violate Sec 144 and open doors for big noncompliance (think an employee quitting on day 364 but a time-bound signature leaving assets up for grabs)

It's just much easier to handle these cases from a distributor account (as you referenced with "unlocked bt a different resigned txn" that manually sends out restricted shares)...

as most sizable lockup cases are significantly more complicated than just X shares on Y date (think management-based performance bonuses, shareholder-approved compensation packages, etc.). 

This is pretty standard today and messing with automating restricting shares via claimable balances out of the gate just presents too many holes for securities violations that we don't think any logical TA would execute such an endeavor for at least a few years.

I understand that you might have pre-signed transactions which have balance amounts messed up post-split, but this is easily rectified by proper sequence management (just ensure claims or signed transactions aren't valid for too long or sequence numbers)

This isn't really a CAP issue, but just more of a trivial notion any secruityholder would need to understand since any stock can execute a split, regardless of any CAP/SEP given an issuer has clawback provisions/trustline revocation.

Given only technical users would generally bother with pre-signed transactions (and pre-signed txns for say interstellar are outside the scope of the issuing anchors and fall onto partaking parties regardless of this CAP), we don't see this nuance as material

Whether we like it or not, shares will be held in Cede for at least the next five years, and that means any securities transfer agent must support stock splits to create any market shift away from centralized TAs.

- John

[John Wooten]

A few updates regarding stock splits:

Upon talking to public CFOs, they are actually quite interested in managing vesting stock like this. They say there would be enough time to cancel claimable balances for outgoing workers since most people leave right after stock vests, not just prior. And edge cases could ideally be handled offline.

A relatively simple implementation of splits can be found here: https://github.com/blocktransfer/stellar-interface/tree/main/investors/splits

All this basically ignores claimable balances, which isn't great because the company would have to update all claimable balances in the case of a stock split, not the asset issuer (i.e. the transfer agent/us).

This could be remedied by having the company account add us as a signer, but that's not ideal when it comes to risk management. And, more importantly, it doesn't let an asset issuer properly execute a split without changing claimable balance amounts for wallets other than the company stock plan (e.g. the investors).

I think this should morph into a proposal for a new issuer operation to manage claimable balance amounts for trustlines with clawback enabled. Thoughts?