Appcoin Law Parte 2: La soluzione SAFT

Marco Santori è un avvocato specializzato in tecnologia finanziaria che vive a New York City, dove dirige il team Tecnologie blockchain presso Cooley LLP.

In questo articolo Opinioni , parte di un serie in corsosullo stato della legge statunitense per quanto riguarda le offerte iniziali di monete e le vendite di token, spiega il significato (e i limiti) della legge recentemente annunciataProgetto SAFT.

Quasi un anno fa, ho dato una spiegazione generalizzata di come alcune vendite di tokenpotrebbe violare le leggi federali sui titolinegli Stati Uniti ho anche dato alcuni suggerimenti su come costruire un token e una rete che evitassero lo stato di sicurezza.

Sfortunatamente, molti venditori di token hanno continuato a vendere token al pubblico prima di sviluppare la funzionalità effettiva della rete in quella che ho iniziato a chiamare una "prevendita diretta". Molti commentatori, me compreso, hanno trovato il modello di "prevendita diretta" una strategia brusca e rischiosa. Ho messo in guardia contro di essa alla fine del mio editoriale di ottobre 2016.

Ora la Securities and Exchange Commission (SEC) degli Stati Uniti ha lanciato il suo colpo all'industria inil rapporto DAO, e altri paesi hanno impostodirettamente divieti.

In questa Parte 2, propongo un'alternativa: un quadro transazionale completo che potrebbesignificativamenteridurre il rischio che il venditore di token entri in conflitto con le leggi sui titoli. Abbiamo lavorato allo sviluppo di questa struttura con alcuni diversi partecipanti del settore, tra cui investitori, emittenti e sviluppatori. Alcuni dei nostri clienti la stanno già testando in natura.

Si chiama SAFT: Simple Agreement for Future Tokens. Ovviamente, è un gioco di parole su Y Combinator SAFE (Simple Agreement for Future Equity). Il SAFT è un contratto tra sviluppatori e investitori. Il SAFTstruttura è un FLOW di transazioni che ha questo contratto al centro.

T abbiamo inventato noi il SAFT. Era utilizzato in modo non esaminato dai venditori di token prima che iniziassimo a suggerirlo. È ora che qualcuno guardi sotto il cofano, però, e verifichi se effettivamente, sai, funziona.

Ad alto livello, il SAFT LOOKS in questo modo:

• Lo sviluppatore di una rete decentralizzata basata su token stipula un accordo scritto, chiamato SAFT, con investitori accreditati. Il SAFT richiede agli investitori di pagare denaro allo sviluppatore in cambio di un diritto sui token una volta completata la rete. Gli investitori solitamente ottengono uno sconto. Gli sviluppatori T emettono token pre-funzionali in questa fase, ma depositano i moduli richiesti presso la SEC.
• Lo sviluppatore usa il denaro per sviluppare la rete. Ciò potrebbe richiedere mesi o anni. Non vengono ancora emessi token pre-funzionanti.
• Una volta che la funzionalità di base della rete esiste, lo sviluppatore crea i token e li consegna agli investitori, che possono venderli al pubblico sul mercato libero per realizzare un profitto.
• Gli sviluppatori stessi possono anche vendere i token al pubblico se lo desiderano.

La differenza SAFT

Si confronti questo processo in due fasi con la prevendita diretta, in cui gli sviluppatori vendono un token pre-funzionante direttamente al pubblico per una consegna immediata o per una consegna in una data futura.

Gli sviluppatori raccolgono milioni di dollari pubblici e usano quei soldi per sviluppare il protocollo di rete per renderlo funzionale. Il pubblico si assume tutti i rischi che il progetto fallisca e lo fa senza il beneficio di principi Dichiarazione informativa standard, doveri fiduciari, elevati standard antifrode o requisiti di accreditamento.

Rimango un sostenitore della vendita di token in generale, ma la prevendita diretta è preoccupante per almeno un paio di motivi. Per KEEP in tema di Parte 1 di questa serie, mi concentrerò su ONE motivo: una prevendita diretta potrebbe essere considerata la vendita di un titolo al pubblico senza una dichiarazione di registrazione o un'esenzione in atto. Ciò è illegale negli Stati Uniti

Penso che il framework SAFT affronti questa preoccupazione in modo elegante. Il SAFT è un documento scritto (disponibile come allegato a questo white paperQui) che LOOKS un SAFE e, come un SAFE, il SAFT è un titolo. Almeno pensiamo che abbia ottime possibilità di essere considerato un titolo, e le parti intendo pienamente che sia ONE.

T stiamo cercando di Evitarele leggi sui titoli qui. Stiamo cercando diutilizzo loro.

Gli investitori acquistano il SAFT non perché intendono utilizzare i token sulla rete una volta che è stato sviluppato, ma perché cercano di vendere i token sul mercato aperto e realizzare il profitto dal loro sconto. Non c'è (o quasi) alcun intento consumistico qui. Gli investitori si aspettano di trarre profitto dagli sforzi dello sviluppatore.

Poiché il SAFT è un titolo, gli sviluppatori lo trattano come ONE. Vale a dire, Seguici le leggi sui titoli quando lo vendono: depositano il modulo richiesto presso la SEC, accreditano i loro investitori (se richiesto) e potrebbero persino far circolare un memorandum di collocamento privato.

Gli investitori inviano il loro denaro di acquisto (in dollari, ether, Bitcoin, ETC.) agli sviluppatori. In cambio, gli sviluppatori firmano un SAFT e lavorano nei mesi o anni successivi per sviluppare la rete in qualcosa di veramente funzionale.

Una volta che è funzionale, gli sviluppatori creano i token e li consegnano agli investitori. Una volta scaduto un eventuale periodo di lockup nel SAFT, gli investitori possono quindi vendere i token sul mercato aperto. Gli sviluppatori possono anche venderli pubblicamente.

Semantica SAFT

La critica più comune a questo approccio è più o meno questa: "OK, il SAFT è un titolo. Hai seguito le leggi sui titoli lì. Ma una volta che gli sviluppatori vendono i token al pubblico, molti acquirenti li compreranno solo per speculare facendo trading in borsa! T è anche quello un titolo?"

Beh, probabilmente no. Ricorda, acquistare qualcosa per rivenderla con profitto su un mercato secondario T rende la cosa un titolo, nemmeno se tutti gli altri aspetti del Prova di Howeysono soddisfatti. La domanda è: da dove può ragionevolmente aspettarsi l'acquirente che provenga l'apprezzamento del valore di mercato secondario?

Ricordate dalla Parte 1, affinché un token sia un titolo, il test di Howey richiede che l'acquirente si aspetti che il suo profitto derivi "dagli sforzi degli altri". Se l'acquirente si aspetta un profitto, ma deriva prevalentemente da qualcosa di diverso dagli sforzi degli altri, la cosa che ha acquistato non è un titolo secondo Howey.

Ad esempio, quando qualcuno acquista diritti su oro o zucchero come prodotto di investimento (vale a dire solo per rivenderli su un mercato aperto), quella persona si aspetta profitti, ma quel profitto T deriva dallo sforzo di una terza parte in particolare. Deriva dalla grande varietà di fattori di mercato che influenzano l'offerta e la domanda di oro o zucchero.

Il prezzo di un token funzionante è determinato in modo simile. Il valore di un token funzionante messo all'uso previsto sarà determinato da una grande varietà di forze globali di domanda e offerta. Per un token pre-funzionale, tuttavia, l'acquirente dovrebbe aspettarsi che ONE forza prevalga sulle altre: gli sforzi dello sviluppatore che ha promesso di infondere funzionalità al token.

Pertanto, il requisito "sforzi altrui" di Howey può essere soddisfatto in modo relativamente semplice da un token prefunzionale.

Una volta operativi, gli sforzi degli sviluppatori continueranno senza dubbio a incidere sul valore del token sui Mercati secondari, ma sarebbe difficile affermare che gli aggiornamenti del protocollo potrebbero essere gli "sforzi essenziali" e "innegabilmente significativi" (entrambi requisiti di Howey) che in genere determinano l'oscillazione del prezzo.

Gli sforzi "essenziali" degli sviluppatori sono stati solitamente già spesi nella creazione della rete funzionale. Gli acquirenti di token su quella rete già funzionale non hanno più bisogno di fare affidamento sugli sviluppatori per spendere quegli sforzi.

In effetti, nella maggior parte dei casi potrebbe essere difficile dire che il movimento del prezzo sia stato causato da qualche "sforzo". Per i token funzionali, i movimenti del prezzo possono essere causati da un qualsiasi numero di forze che influenzano domanda e offerta. Per usare esempi dal white paper del Progetto SAFT: un token che funge da mezzo di scambio su un mercato decentralizzato per la potenza di elaborazione grafica (questo ONE sto inventando) potrebbe fluttuare con l'uscita di un franchise di videogiochi di successo o la disponibilità di elementi di terre RARE utilizzati nell'elaborazione delle schede grafiche.

Un token che funge da semplice coupon per una scatola gratuita di lamette da barba (che costituisce anche ONE ) potrebbe fluttuare con il prezzo dell'acciaio, o persino con la popolarità delle barbe in un mercato target. Di sicuro, gli sforzi manageriali dei venditori di token nell'aggiornare la rete saranno un fattore nel prezzo, ma lo saranno predominaretutte le altre forze? Per un token già funzionante, non spesso.

Raggiungere un equilibrio

In una transazione SAFT, le leggi sui titoli relativamente severe si applicano nelle fasi iniziali, quando l'intero progetto potrebbe fallire e sono più necessarie.

Ricorda che il SAFT è un titolo, quindi alla transazione si applicano le disposizioni anti-frode, i requisiti degli investitori accreditati e simili. Le leggi più gestibili sulla tutela dei consumatori si applicano una volta che la rete è funzionante e, come minimo, gli acquirenti si aspettano che la rete funzioni.

Quindi, il quadro SAFT richiede leggi sui titoli quando l'acquirente assumerischio d'impresa, e chiede che siano rispettate le leggi sulla tutela dei consumatori quando l'acquirente assumerischio del prodotto. Ciò ci ha colpito, noi autori del white paper, come la giusta situazione, e pensiamo che il SAFT ci porti lì.

Detto questo, ci sono molte limitazioni alla flessibilità del framework SAFT. Ad esempio, il SAFT:

• T è necessario per gli sviluppatori che possono vendere un token funzionale direttamente al pubblico il ONE giorno. Il SAFT colma le insidiose acque normative tra l'accettazione di fondi e la consegna di un token funzionale. Se hai già sviluppato un token funzionale, la necessità di un SAFT è discutibile.
• T ottiene molto per i token che sono essi stessi titoli (ad esempio interessi di società in accomandita semplice come il token DAO). L'utilizzo di un SAFT T renderà un token di titoli meno di un titolo. Il SAFT funziona solo per "token di utilità."
• T aiuterà nemmeno i token di utilità in cui gli acquirenti continuano a dipendere dagli sforzi dei venditori di token (o di altri) per le loro aspettative di profitto Dopoil token è in circolazione. Esempi includono situazioni in cui il venditore si affida alle promesse dell'emittente di riacquistare i token per aumentare il prezzo, o in cui il venditore promette di sviluppare la funzionalità veramente preziosa a un certo punto dopo la vendita.

Anche comprendendone i limiti, il SAFT T è ancora pronto a fungere da standard di mercato. ONE , l'analisi che abbiamo fatto è limitata alla legge statunitense. Un altro motivo è che i termini commerciali del SAFT sono scarni e basilari.

Per queste e altre ragioni, abbiamo lanciato il Progetto SAFT. È pensato per essere un forum di discussione e condivisione di idee sul framework SAFT. La nostra porta è aperta a suggerimenti e critiche.

Nella terza parte di questa serie, intendo discutere alcune delle migliori pratiche SAFT, tra cui le strategie di gestione fiscale e i tipi di token più compatibili con il framework SAFT.

Hai un'idea per una disposizione commerciale per il SAFT? Una critica alle argomentazioni normative che la supportano? Hai notato una considerazione Politiche che abbiamo trascurato? Pensi che tutta questa faccenda del SAFT sia destinata a fallire? Vorremmo sapere perché! Contribuisci al progetto SAFT.

Parti dell'orologioimmagine tramite Shutterstock