USD Coin

스마트 컨트랙트 기반 스테이블코인

홈페이지 https://www.centre.io/usdc

참고자료

커뮤니티

시세
1,149.07 KRW
상장된 거래소
9
심볼
USDC
출시 예정
프로젝트 소개

USD Coin은 Coinbase와 Circle이 창립멤버로 참여한 CENTRE가 미국 달러를 담보로 발행된 스테이블 코인입니다. 이론적으로 1 USDC는 담보자산인 1 미국 달러에 연동하여 가치를 유지합니다.

경영진 및 파트너사
등록된 경영진이 없습니다.
해당 팀에게 응원 메세지를 남겨주세요!

Goldman Sachs

BITMAIN

최신뉴스

등록된 뉴스가 없습니다.
해당 팀에게 응원 메세지를 남겨주세요!

메세지 남기러가기

미디움

USDC redemptions approach ...

To provide continued transparency about USD Coin (USDC), we wanted to highlight some data about redemptions and provide some clarity about why making redemptions seamless is an essential element of USDC’s success.USDC redemptions have reached about $388 million since its launch in late September. In total, there have been just over 400 distinct burn events.We believe redeem-ability is a key attribute of a robust, liquid fiat token. We are constantly looking for ways to make the process of redeeming USDC back to funds on a bank account as fast and frictionless as possible. We have minimized the time between a redemption request and the corresponding burning of tokens / initiation of the bank wire transfer, and connected to specific bank networks that allow for real-time settlement. We will continue to improve our service to deliver best-in-class redemption.Part of what has made USDC the second largest stablecoin by market cap is its openness and interoperability. USDC was launched through the CENTRE Consortium, a joint venture between Circle and Coinbase. That means regardless of where someone mints their USDC, they can redeem them at either Circle and Coinbase, and at any other future issuer.USDC redemptions are free with both Circle and Coinbase because we believe price-stable assets like USDC are foundational for enabling powerful new global financial contracts, products, and services on the internet. If you want to redeem, follow these helpful steps: Circle Redemptions | Coinbase Redemptions. For an overview of fees applicable to USDC, check these help center articles: Circle Fees | Coinbase Fees.USDC redemptions approach $400 Million was originally published in CENTRE blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

USD Coin

19. 03. 22

Designing an upgradeable E ...

CENTRE will be a governed network powered by price-stable crypto assets (see whitepaper). Our first contribution is the USD Coin (USDC): an Ethereum ERC-20 token that is redeemable into USD. You can trade the USDC token on Poloniex and other digital asset exchanges. The total supply will be determined by CENTRE approved Issuers who maintain reserves in escrowed accounts and then get permission to mint tokens. You can look at our contract on Etherscan, as well as the source code and design overview on GitHub. The main contract is FiatTokenProxy that forwards all function calls to FiatTokenV1.Circle (and any future issuer) has an obligation to its customers that extends beyond the written code of the smart contracts CENTRE deploys. We chose to write a Ricardian smart contract: CENTRE will use the USDC smart contract to implement controls relating to Circle’s obligations to its USDC-holding customers and we have created a mechanism that will let us change the code if we determine that Circle is not fulfilling its part.But how do you upgrade an Ethereum contract?Upgrading Smart ContractsEthereum lets anyone put code on the blockchain. Ethereum assigns the code an address, and anyone can call functions on the code stored at that address. No-one can ever change the code at a particular address, not even the owner. Software upgrades have to be done using address pointers and redirection techniques.There are several challenges:We needed a persistent data storage contract for our data. The USDC contract needs to store balances for millions of users, and migrating the data to a new contract would be expensive.We needed a mechanism to change which smart contract had permission to write to the persistent storage. This would be our upgradeable logic contract.Users and large ERC-20 token exchanges needed to be oblivious to a USDC logic contract upgrade. CENTRE had to publish a single USDC contract address that would be valid even after an upgrade.The upgrade mechanism had to be as simple as possible to enable through testing.Eternal unstructured storageWe first looked at Rocket Pool’s eternal unstructured storage model. In this model, the USDC token would consist of two contracts: a FiatToken contract that writes to an EternalStorage contract. In case of a problem, we would deploy FiatTokenV2 and tell EternalStorage about the upgrade.EternalStorage would contain mappings to store data of every basic Ethereum data type. For example, to store a uint256, EternalStorage would use the state variable:mapping(bytes32 => uint256 private uIntStorage;Each mapping would have corresponding getter and setter functions:function setUint(bytes32 key, value) onlyLogicContract { uIntStorage[key] = value;}FiatToken would use the sha3 hash of the variable name as the key to the mapping. To store totalSupply=5000, FiatToken would call:setUint(sha3(“totalSupply”), 5000).The mapping between user accounts and their balance would have to be stored assetUint(sha3(“balance”, accountAddress), value);We discovered that this simple design is very dangerous! Ethereum tightly packs input to the sha3 hash and then pads it at the end with 00 to get an input length that is a multiple of 32 bytes. This means sha3(A,B) can equal sha3(C,D) because of how EVM parses the input.The chief mitigation is using length-encoded input. However, it still does not guarantee collision free keys. We wanted a more robust approach.Eternal structured storageOur next thought was to replace the unstructured mappings with data specific variables:uint256 totalSupply;mapping(address => uint256) balance;mapping(address => bool) blacklisted;bool paused;We wrote specific getters and setters for each variable inside the EternalStorage contract. Then we wrote a parallel set of getters and setters inside the FiatToken contract to call the EternalStorage contract.Our codebase rapidly increased in size. The list of variables above is only a small subset of the variables in our actual USDC contract. We needed a simpler approach that was easier to analyze and reason about.More problems with EternalStorageThe EternalStorage model had a bigger problem. The main USDC contract would be FiatToken. After an upgrade, even though EternalStorage would know about FiatTokenV2, the token owners and token exchanges would not. Every FiatToken function had to check whether EternalStorage was using a different logic contract and redirect the call. Our codebase grew even more.Proxy ModelConsenSys Diligence strongly encouraged us to switch to the Zeppelin OS proxy model.In the proxy model, the main contract is a proxy with almost no logic of its own. Every call to the proxy contract gets sent to the fallback function and then forwarded via a DELEGATECALL to the current implementation — our FiatToken contract. Since this is a DELEGATECALL, the FiatToken reads and writes directly to the storage of the proxy contract.The beauty of the proxy model is that we can switch the implementation contract without affecting our users. Individuals and exchanges would continue to call ERC-20 functions on the proxy.One of our smart contract developers rewrote our entire contract to create a new prototype. He replaced our EternalStorage with a proxy and deleted about 75% of the code. What remained was a simple contract with no function calls or if-then statements. It was much easier to understand and we could be confident we gave it full unit test coverage (more in another blog post). We had a winner!The proxy approach solved all our problems. We deployed the AdminUpgradeabilityProxy as our main USDC contract. It is an advanced version of the basic proxy with special guards against malicious backdoors.Contract migrationBefore settling on the upgradable proxy approach, we considered several other alternatives. To begin with, the very concept of an upgradeable smart-contract is controversial. One of reviewers, Trail of Bits, recommends contract migration instead of contract upgrades because upgradeability increases code complexity. Contract migration requires notifying all users of a new contract address. We were concerned about the operational challenges of coordinating the migration of a widely traded ERC-20 token.Trail of Bits also identifies interesting issues with where the Solidity compiler stores variables in proxy and implementation contracts. We avoid these problems by using a simple proxy that does not share any common variables with the implementation. We also tested several upgraded implementation contracts to ensure consistent variable layout.Upon weighing all concerns required to meet our obligations to our customers, we chose to use the upgradable proxy pattern. We did so based on the strength of the extensive testing and community confidence in Open Zeppelin libraries, operational simplicity, and our own comprehensive design and review process.Advice on using proxied contractsWe would like to offer some general advice to developers who want to use the proxied contract design pattern.The implementation contract writes to the proxy contract, but it stores data based on the order in which the variables are declared in the implementation. To upgrade to a new implementation, developers must declare the same variables in the same order. The easiest way to ensure this is to have the new implementation inherit from the original. We created several test versions of FiatTokenV2 to ensure we can upgrade successfully.The ReadContracts tab on Etherscan does not work with proxied contracts. Users can still see the ERC-20 token properties such as balances, total supply, etc. This is because data is stored in the proxy contract, but the proxy has no getter functions to notify Etherscan that they exist. Reading all the contract data requires custom tooling.The AdminUpgradeabilityProxy we used as a base class does not have getters for the admin and implementation address. Developers need to either create getters in the implementation contract or manually retrieve their value from the blockchain using the web3js getStorageAt() function.We are very grateful to our external reviewers, Trail of Bits and ConsenSys Diligence. They gave us invaluable design and testing advice, and caught several subtle (and not so subtle) issues.Designing an upgradeable Ethereum contract was originally published in CENTRE blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

USD Coin

18. 09. 26

거래소
거래소 마켓 시세 거래량 주소
Binance 추후 제공 추후 제공 추후 제공 바로 가기
OKEx 추후 제공 추후 제공 추후 제공 바로 가기
Kucoin 추후 제공 추후 제공 추후 제공 바로 가기
BitBay 추후 제공 추후 제공 추후 제공 바로 가기
SouthXchange 추후 제공 추후 제공 추후 제공 바로 가기
BitMart 추후 제공 추후 제공 추후 제공 바로 가기
CoinExchange 추후 제공 추후 제공 추후 제공 바로 가기
DDEX 추후 제공 추후 제공 추후 제공 바로 가기
YObit 추후 제공 추후 제공 추후 제공 바로 가기
취약성 검증

해당 팀의 취약성 검증 결과가 없습니다.
취약성 검증은 왜 필요할까요?

더 알아보기

코멘트 0

* 작성된 질문 내용은 수정 변경이 되지 않습니다.

* 질문에는 토큰팀 담당자가 직접 답변합니다.

Information
Platform ERC20
Accepting
Hard cap -
Audit -
Stage -
Location -
주요 코인 시세 *2019년 03월 27 기준

비트코인

BTC

4,509,059.58 KRW 0.46%

이더리움

ETH

153,342.48 KRW 0.39%

리플

XRP

343.89 KRW 0.01%

라이트코인

LTC

66,804.38 KRW 0.92%

이오스

EOS

4,182.27 KRW 0.46%

비트코인 캐시

BCH

180,966.58 KRW 0.97%

바이넨스 코인

BNB

18,605.68 KRW 1.08%

테더

USDT

1,145.68 KRW 0.33%

스텔라루멘

XLM

117.12 KRW 0.90%

카르다노

ADA

70.01 KRW 5.62%

트론

TRX

25.66 KRW 0.39%

비트코인 사토시 비전

BSV

72,293.64 KRW 0.70%

모네로

XMR

59,812.78 KRW 1.02%

대쉬

DASH

102,042.20 KRW 0.22%

메이커

MKR

815,656.53 KRW 0.03%

네오

NEO

10,119.68 KRW 0.40%

온톨로지

ONT

1,321.65 KRW 1.97%

이더리움 클래식

ETC

5,291.39 KRW 0.52%

XEM

55.95 KRW 0.37%

테조스

XTZ

758.40 KRW 3.44%