Descrption：USDC is a fully collateralized US dollar stablecoin. It is an Ethereum powered coin and is the brainchild of CENTRE, an open source project bootstrapped by contributions from Circle and Coinbase. USDCs are issued by regulated and licensed financial institutions that maintain full reserves of the equivalent fiat currency in a 1 USDC:1 USD ratio. Issuers are required to report their USD reserve holdings frequently, and Grant Thornton LLP issues reports on those holdings every month.
Principle and design goals
As underlying enablers of solutions to the
aforementioned use cases, blockchain technology
and crypto assets promise many benefits: a
transparent distributed mechanism for managing
trusted updates to shared data among parties
who have varying degrees of trust between one
another; and a transferable store of value that
is not tied to the policy of an issuing sovereign,
but rather value based on the processing power,
work, stake, and markets that support it.
At the current time, however, existing public blockchain
implementations and crypto assets struggle to fulfill
the vision in part due to three significant challenges:
price stability, transaction throughput, and risks due to
the lack of independent governance over standards
and network participants (particularly those members
offering trade capability and fiat on- and off-ramps).
Firstly, price volatility: In order for global financial
interoperability to function reliably and consistently,
a price-stable medium of exchange and store of
value is desired. Transacting in currencies which
fluctuate with extreme volatility creates complexity
and fragile settlement contracts, especially
when compared to transacting in “tokenized
fiat money” or fiat-pegged crypto assets.
CENTRE meets this challenge by providing a
stablecoin framework involving “real world” asset
reserves. Each stablecoin token corresponds to a real
world asset that is reserved by an issuing CENTRE
network member and verified and audited by CENTRE.
For example, a network member such as Circle
might choose to provide a tokenized dollar and
tokenized euro, and back such tokens with a
reserved dollar and euro, with CENTRE auditing
Circle to ensure compliance and solvency. In
theory, another network member might tokenize
another asset, such as gold, and similarly back
that token with physical gold in reserve. Rules
concerning limits, proofs, etc, would be enforced
by CENTRE on each issuing network member.
A second challenge with current technology is
blockchain transaction throughput. Current public
blockchain implementations do not support highvolume
performance, as every transaction is written
to an underlying ledger and printing new blocks to
such ledgers currently involves relatively high latency.
CENTRE addresses this challenge by providing a
protocol for wallets to transact at higher velocity using
state channels. The initial and final settlement states,
such as account balances, of an interaction between
two participating members is written to the relevant
underlying blockchain, but intervening transactions
are not written to the underlying chain and thus
executed at the speed of the internet. This allows
for payments in tokenized fiat currencies but with
the speed, security, and auditability of blockchains.
A third challenge with existing implementations is
the lack of independent governance over stablecoin
providers. An issuing institution must be independently
audited for solvency and security, otherwise
the underlying asset cannot be independently
verified, and the price stability becomes tenuous.
This issue has arisen with previous attempts at
fiat-asset-backed stablecoins in production.
CENTRE addresses this issue through separation
of the CENTRE organization from its issuing
network members. CENTRE itself is not an issuing
member or financial institution, but a network
scheme manager and technology provider. CENTRE
enforces compliance with network rules around
membership and behavior in order to ensure
stability, accountability, and consumer protection.
CENTRE plans to implement the protocols
on top of Ethereum as a series of smart contracts
and ERC20 tokens. CENTRE plans to leverage the
existing implementation to accelerate development
of a new implementation of the protocol.
The Consensus mechanism is PoW.
Accounts and transactions
To transfer tokens at higher throughput rates, as
an option in addition to direct usage of Ethereum,
CENTRE transactions can utilize the state channel
pattern. Using this option, nodes exchange balance
information in the form of tokens transferred
in state channels. This section describes how
state channels operate at a conceptual level.
State channels are a way for two or more participants
to update shared state between them securely
without executing transactions on a distributed ledger,
except for creating and finalizing the state channel
on the ledger. State channels are similar to payment
channels, but state channels can manage multiple
types of shared state in addition to payment data.
To create a state channel, the participants agree
to an initial state and execute transactions on
an underlying distributed ledger in order to
lock in that state. Subsequent updates can be
executed without executing any transactions on
the ledger. Each update is simply a new state,
and each participant cryptographically signs the
new state if it is valid. When the participants wish
to close the channel, they can each execute a
transaction saying they agree to the final state.
For example, imagine Alice and Bob wish to create
a state channel for payments. They each lock 100
US dollar tokens into a state channel contract
on the ledger, for an initial state as follows:
Thereafter, Alice and Bob can perform updates by
communicating between themselves: When Alice
sends 50 euro tokens to Bob, she does so by
generating a new state, cryptographically signing it,
and sending it to Bob. If Bob agrees to the new state,
he signs it and sends it back to Alice. The new state
between them looks as follows:
If Bob then sends 25 tokens back to Alice, he
generates a new state, signs it, sends it back to
Alice, who signs it, producing another new state of:
When Alice and Bob wish to settle these payments,
they do so by closing the channel. Alice executes
a transaction reporting that she agrees to the final
state; Bob agrees, so he also executes a transaction
agreeing to the final state. Since they agreed, the
state channel contract then sends the funds to each
participant based on the final state it was given. In
this example, Alice receives 75 euro tokens and Bob
receives 125. The net change of 25 tokens from Alice
to Bob is committed to the ledger. Any intermediate
state changes will never be committed to the ledger.
When one party wishes to close a channel,
the state channel contract does not close
immediately on demand. Instead, a challenge
period commences in which the other
participants have a period of time to either:
• Agree, in which case the channel is closed and
the changes are committed immediately;
• Dispute the final state by submitting a state signed
by all parties with a higher sequence number; or
• Do nothing, which will constitute agreement
once the challenge period expires.
Imagine the scenario in which Bob wished
to “cheat” by broadcasting the earlier state
which assigned him 150 tokens instead of 125
tokens. That state was also signed by both
Bob and Alice, so it is in some sense valid.
In this example, if Alice disagrees with the final state
that Bob submits, then she would have a chance
to submit the later state (sequence 2), which was
also signed by both parties; in this example, that
would supersede Bob’s final state. Bob could then
either agree or do nothing. He would be unable to
dispute since he does not have a later state signed
by both parties. This means that no participant
can prevent another participant from closing the
channel, and no one should be able to close the
channel except with the legitimate final state.
Further, the reputational impact of any party
attempting to cheat the network is recorded and
subsequently visible to other participants.
Smart contract system
Distributed storage protocol
Cross-chain and exchange technology
State channels can be chained to enable payments
to additional parties. If Alice wishes to pay Carol,
and both Alice and Carol have a channel with Bob
but not with each other directly, then the transfer
from Alice to Carol can flow through Bob and then
on to Carol without requiring Alice and Carol to
open a direct channel. To chain state channels in
this manner, the system must enforce assurance
that when Alice pays Bob, that Bob will in turn pay
Carol and that Bob cannot retain the funds himself.
This is accomplished through the use of a hashed
time locked contract (HTLC), which makes executing
the chained payment as secure as executing it
through a normal direct state channel. A chain
of states is established in which the funds will be
released if and when the recipient can produce a
secret. The final recipient is then given the secret,
which they pass up the chain, and everybody in
the chain can use the secret to claim the funds.
In this example, Alice gives Bob a new state that
essentially states: “if you can produce the preimage
that will produce this hash, then you can receive the
funds.” Bob then produces a similar state with Carol.
Alice then gives Carol the preimage. Carol uses
that preimage to retrieve the funds from Bob, and
then Bob uses that to retrieve the funds from Alice.
Since the HTLC is enforced by the state channel, if
one party attempts to steal the funds then the other
party can broadcast a transaction with the HTLC and
the preimage, which will direct the funds to them.
Economic model and incentive
No contributors information for the version. to see perfessional version!
No analysis results for the version. to see perfessional version!