#NYDFS issues USD backed #stablecoin guidance; must be fully backed by an asset reserve; issuer must adopt a clear redemption policy, approved by DFS in writing (!!!) redemption at par in fiat; reserve must be held in custody with /1 dfs.ny.gov/reports_and_pu…
US state/federally chartered depository institutions and/or asset custodians. Reserve must be held in govt treasuries "subject to DFS- approved reqs re: overcollaterialiation." Reserve must be subject to independent audit 1x month by independent CPA under AICPA attestation /2
standards. DFS may also impose obligations regarding cybersecurity and IT standards and evaluate issuer BSA/AML & Sanctions compliance, safety and soundness of the issuing entity; and the stability/integrity of the payment system, as applicable on Issuers. /3
DFS may impose "different requirements" on any #stablecoin backed by #USD & will require clear and conspicuous disclosure of any such different requirements. /4
Currently approved: #Paxos#USDP, #BUSD; #Gemini#GUSD, #ZUSD; Does not applyto USD-backed stablecoins listed, but not issued, by DFS-regulated entities but DFS expects "regulated entities that list USD-backed stablecoins" to consider this guidance when submitting a request /5
for coin issuance/ seeking approval for a coin self-certification policy. Expect ongoing iteration of this guidance and engagement by DFS with industry to learn more. Link to full guidance here: dfs.ny.gov/industry_guida…
guidance allows issuers to redeem net disclosed fees (permits income beyond treasuries yield); redemption must be "timely" i.e. T+2. DFS can vary this time when "timely redemption would likely jeopardize the Reserve’s asset-backing or the orderly liquidation of Reserve assets" /6
reserve assets must be held by state/federally approved institutions or custodians who are pre-approved by DFS & segregated from proprietary assets of issuer; reserve assets must be govt treasuries or DFS pre-approved deposit accounts /7
CPA attetsation must cover amount of stablecoin outstanding, issuer reserve, whether reserve at all times was sufficient to cover outstanding units of stablecoins and whether DFS imposed conditions were met at all times; /8
also requires annual attestation by CPA of management controls; monthly attestations made public within 30 days; annual attestation made public within 120 days; /9
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Take aways from the #blockfi settlement with the #SEC (sec.gov/litigation/adm……) 1. BIA were notes under the Reves test; one factor is that there is "no alternative
regulatory scheme or other risk reducing factors exist with respect to BIAs" Congress can of course, set out a /1
an alternative framework that would potentially push these sorts of ventures into a different regulatory classification. 2. the offer and sale of notes is an investment contract. Yes, you can be debt and an investment contract; the pooling of assets is the key factor here. /2
3. Blockfi was a 40 act company; 40% of its assets were investment securities - including loans. /3
There has been lots of talk about #uniswap front end interfaces blacklisting #tokens that might be #securities. This is not an attack on #DeFi or regulation of #DeFi specifically, but instead a logical example of how existing regulation applies to legally addressable entities /1
including those that facilitate the use of #decentralized systems- in this case, legally addressable interface providers. And this isn’t new. Quietly, many front end providers are also engaged in #sanctions compliance. While laws obviously apply to legally addressable actors, /2
this does not mean that regulation has applied or will be applied directly to protocol code, at least not yet. This is b/c code itself is not legally addressable. It has its own rule-set governing its environment, & law cannot change code, although law can act on people /3
These ventures use code to enable groups of people to act collectively to affect rights to #digital assets. We call these “decentralized ventures.” These decentralized ventures enable transactions among their participants in accordance w/rules created and enforced by their code;
human participants in these decentralized ventures interact with the venture, & sometimes with each other, using #smartcontracts. Smart contracts may break, or behave in unexpected ways. What happens when a smart contract defect /error harms a decentralized venture user?
We've got a new proposed #SEC#token#safeharbor that would let issuers offer tokens in the US. It's big. But, what's new? How is it different from the prior proposal? What's new? You guessed it. It's unavoidable, It's inevitable. It's a #THREAD. Let's dive in/1
Right off the top, we have the elimination of the "good faith" provision that was previously implied upon the issuers in a(1) & of a(4) which required the issuer to act in good faith to "create liquidity for users." /2
New section a(5) includes reference to the new "Exit report" which is a new requirment defined and explained further down but tldr; its a report issued by the issuer's counsel that asserts whether the tokens will be a security or not after the 3 year period. Good inclusion /3
3 most significant changes: mandatory semi-annual updates to the plan of development disclosure and a block explorer; exit report requirement with analysis by outside counsel explaining why the network is decentralized or functional, or an announcement that the tokens will