Wyoming Administrative Code › Agency 021 - Audit, Dept. of › Sub-Agency 0002 - Banking Division › Chapter 19 - ENHANCED DIGITAL CUSTODY OPT-IN REGIME › Section 19-5 - Customer Protections; Requirements for Customer Agreements

Current through July 13, 2024
(a) A bank and a
				customer shall agree in writing regarding the source code version the bank will
				use for each digital asset, and the treatment of each asset under the Uniform
				Commercial Code, title 34.1, Wyoming statutes, if necessary. Any ambiguity
				under this subsection shall be resolved in favor of the customer.
(b) A bank may periodically determine whether
				to implement a source code version that uses block validation rules different
				than those of the source code version specified in the customer agreement under
				subsection (a) of this section, including in circumstances where is not
				possible to predict in advance whether utilization of the different source code
				version will be in the best interests of the customer. Additionally, the nature
				of proposed changes to source code versions from time to time may require the
				bank to consider the potential effects resulting from third-party actors (a
				person not a party to the agreement between the bank and its customer), who may
				create different source code versions resulting in new networks that could
				create economic value for the customers of the bank. Banks shall not be
				required to support digital assets and source code versions which the bank has
				not entered into an agreement with customers to support. Banks shall not
				capriciously redefine the digital assets under their custody, and the
				Commissioner shall have discretion to determine whether a redefinition is
				capricious. In communicating with customers regarding the situations set forth
				in this subsection, banks shall have a duty to provide higher standards of
				customer notice and acknowledgement if there is likely to be a material impact
				on the economic value of the customer's digital asset. Customer agreements and
				notifications shall clearly describe the consequences of hard forks without
				replay protection, as required by the Commissioner, and how that may cause the
				transfer of assets that were previously in bank custody without explicit
				instructions to the bank, accounting for the fact that some forks allow valid
				transactions from another distributed ledger to also be valid on the fork. In
				the event of a replay protection attack by a new hard fork, the bank may pause
				withdrawals and investigate appropriately. As used in this paragraph, "replay
				protection" means, in the case of a digital asset fork, the ability to
				duplicate a transaction made on one fork of a distributed ledger to another
				fork. When changes to source code versions occur that use different block
				validation rules than those of the source code version specified in the
				customer agreement, the following customer notice and acknowledgement rules
				shall apply:
(i) If the bank chooses not to
				continue to support the original source code version agreed upon with the
				customer pursuant to subsection (a) of this section, it shall receive written
				affirmative consent from the customer as provided in this paragraph. Notice and
				affirmative consent are only required under this paragraph when the conditions
				in subparagraphs (A) through (C) occur:
(A)
				The bank seeks to implement a source code version that uses a consensus rule
				that differs from the original, as defined by the source code version specified
				in the customer agreement pursuant to subsection (a) of this section;
(B) The bank will not continue support for
				the original source code version; and
(C) The original source code version
				continues to exist, or is reasonably expected to continue to exist.
(D) The following examples apply to this
				paragraph:
(I) A hard fork of virtual currency
				"B" created a new source code version, "New B." Consequently, if a bank stopped
				supporting B but did choose to support New B, then the notice and affirmative
				consent requirements of this subsection would apply. For illustrative purposes,
				"New B" and "B" could be considered as similar to the virtual currencies
				"Bitcoin Cash" and "Bitcoin," respectively.
(II) A hard fork of virtual currency "E"
				created a new source code version, "New E," and followed the block validation
				rule change contained in the newly created source code version. The original
				source code version of E did not change but was renamed "E-Classic" and
				continued to follow the original block validation rules. Consequently, if a
				bank supported New E but no longer supported E-Classic, then the notice and
				affirmative consent requirements of this subsection would apply. For
				illustrative purposes, "New E" and "E-Classic" could be considered as similar
				to the virtual currencies "Ethereum" and "Ethereum Classic,"
				respectively.