The SEC is about to run bitcoin nodes, just to get the blockchain internal data

With the principle of holding hands over thousands of times, the SEC experts finally decided to run a bitcoin node that belongs to them.

Recently, the SEC posted a list on the Federal Business Opportunities, which shows that the SEC is hiring a contractor for specific quantities such as Bitcoin, Ethereum and Ripple. Blockchain operation node.

In terms of government functions alone, the US SEC is similar to the domestic CSRC, and the SEC's announcement of the cryptocurrency ecology also means that the cryptocurrency ecosystem has officially begun to connect with the government, which is significant.

For the SEC, in fact, its fundamental purpose is to bypass the blockchain data provided by third parties, so as to collect and analyze blockchain data from within.

To this end, in addition to the requirements of the "contractor" itself technology, price, business, etc., the SEC also issued a detailed list of requirements for "node data provision".

The following is the SEC requirements list details:

The US Securities and Exchange Commission (SEC) requires a data source for blockchain ledger data to support its efforts to monitor risk, improve compliance, and inform the committee about digital asset policies. This data source includes but is not limited to the following requirements:

Blockchain type and composition

1. The data source should include at least Bitcoin and Ethereum blockchain

2. In addition, the data source should include as many of the following blockchains as possible: BCH, Stellar, Zcash, EOS, NEO, and XRP

3, the data source must support the addition of new blockchain, because these blockchains have gained a prominent position in the market

4. The data source should obtain all blockchain data from the managed node instead of providing this data as a secondary source (for example, via a block browser).

5. The data source shall include all tokens (Tokens) of all provided blockchains.

6. The data source shall include the complete blockchain ledger of the genesis block or all existing provided blockchains.

Required data field

1. The data source should include all node data for each blockchain provided.

2. The data source shall include at least the normalized fields of each of the following blockchains:

Ticker code

Address (send/receive)

Transaction hash

Transaction timestamp

The transaction amount

Unspent balance (send/receive)

transaction fee

Confirmations

Block hash

Block height

3. Happy to own: Provide cross-referenced data to support attribute intelligence on blockchain transaction data.

4. Happy to own: Provides an overview of the blockchain provided, including metadata and chain metrics. These data include hashing algorithms, hashing power, mining difficulty and rewards, number and size of transactions, token supply, and blockchain size.

Data normalization and quality

1. The vendor must run its own node for each supported blockchain. Each node must be synchronized with the network, and all processes run in a secure and controlled environment.

2. Provide methods to demonstrate that all data provided is accurate and complete.

3. Provide data across different data sources in a standardized manner to facilitate data viewing and use.

4. Provide clear definitions and rigorous metrics for calculating all derived metrics.

5. Prove that the rigor of data cleansing and standardization is in line with the requirements of financial statement audit testing.

6. If attribute data is provided, describe the process and data source for mixing blockchain data and attribute data points for in-depth insights.

Data supply and frequency

1. Data should be sent to the committee using secure, encrypted data.

2. You must use one of the following transport protocols: SFTP or IBM ConnectDirect. For SFTP, authentication can be done with a public or private key.

3. The Data feed shall provide all historical information of the complete blockchain at one time, including all historical information from the genesis block or available, and provide updates every day thereafter.

4. Provide enterprise data licenses: Data must be enabled for full use by the enterprise, including data access and data sharing.

5. Happy to own: Provide an additional API transfer option.

Answers about some issues with the SEC

 

1. When the SEC asks, how much time do you want the contractor to spend adding a new blockchain?

We need to be able to add new blockchains in the future as they are getting more and more attention. The acceptable time range for adding a new blockchain is 1 to 3 months

2. When referring to "should include all node data", is it interested in the script/smart contract code itself?

According to the list of requirements, all node data should be included, script/smart contract code and transaction data are required.

3. Will it benefit from real-time data updates (by push)?

The minimum frequency requirement is a daily update for each requirement

4, on the required data fields

Q: What reference code do you want the contractor to use? Does the name of the encrypted asset and the unique blockchain ID meet the requirements?

We require that individual assets be identified by market standard codes (ie, in the absence of actually defined standards, using market practices) and blockchain IDs.

Q: Do you agree with the definition of "confirmation number", and the "confirmation number" is to subtract the latest number from the number you are interested in?

Whenever a new block is added, the confirmation number for all blocks changes. Typically, the explorer provides a block number and a Tx number. This information is sufficient for our purposes.

Q: When referring to "cross-reference data supporting attribution intelligence", does it mean attribution to metadata only , or is it used to attribute metadata to blockchain accounts?

This refers to cross-referenced off-chain data that provides attribute intelligence for the provided blockchain transaction data (and metadata).

5. About "Data must be enabled for full use by the enterprise, including data" access and data sharing:

Q: Do you require data to be shared outside the SEC?

Yes, in a sense, data elements can be used to support committee functions, such as law enforcement actions and legal actions. However, the use of such data is limited and the Commission's business can only be supported when necessary.

Q: Is the original data required to be shared?

Raw data can be shared between all SEC users. However, if it is necessary to support the committee's legal proceedings and other functions, only a small part of the data can be shared outside the Securities and Exchange Commission.

Q: Is it sufficient if the license allows sharing of derivative works (such as summary statistics) instead of raw data?

No, because there may be situations in which the Commission requires the use of raw data to support committee functions (such as legal proceedings). However, the use of such data is limited and the functions of the committee can only be supported when necessary.

6. How long will the US Securities Regulatory Commission expect contractors to provide data updates to the SEC? How often does the US Securities and Exchange Commission expect contractors to provide updated blockchain ledger data?

Once a day, as required.

7. How to determine the accuracy and completeness of the data? Does the US Securities and Exchange Commission have a hypothetical data set to measure?

We are looking for suppliers to prove that the data provided is accurate and complete. An example of how this can be done is to describe the application's data procurement and quality assurance processes.

8. Please elaborate on the rigor of data cleansing and normalization, which will be sufficient to prove to the SEC that the requirements for auditing the financial statements have been met.

The supplier shall describe the data cleansing and normalization process applied, as well as the associated quality assurance, and demonstrate that sufficient steps have been taken to ensure the accuracy of the data.

Original: Sharing Finance Neo