Official repository for core projects comprising the Celo platform
APACHE-2.0 License
Bot releases are visible (Hide)
Published by aaronmgdr about 2 years ago
celocli releasegold:admin-revoke
command by @yorhodes in https://github.com/celo-org/celo-monorepo/pull/8749
celocli network:parameters
by @yorhodes in https://github.com/celo-org/celo-monorepo/pull/8651
Published by aaronmgdr about 2 years ago
grandamento:execute
, grandamento:get-buy-amount
, small fixes, and some Granda Mento wrapper fns by @tkporter in https://github.com/celo-org/celo-monorepo/pull/8612
Published by 0xarthurxyz about 2 years ago
This is the eighth release of the Celo Core Contracts. It follows the release process per the docs.
Release 8 adds a new identity registry contract, FederatedAttestations.sol, to the Celo Core Contracts. Similar to Attestations.sol, this new contract records mappings from bytes32 identifiers to addresses, and is used primarily to resolve off-chain identities like phone numbers to addresses so that users can more easily send each other payments. The Federated Attestations protocol introduces 'trusted' issuers that verify claims about a user's identity, such as their phone number (see this doc for more info). In the original Celo identity protocol, Attestations.sol mappings can only be updated by a fixed 'issuer', which is a randomly selected quorum of 3 Celo Validators that must each verify the user's phone number by sending separate SMS messages. This design minimizes trust requirements, but leads to subpar UX and performance. The FederatedAttestations.sol contract partitions the identifier to address mapping by issuer so that users of the contract can filter for mappings verified by issuers they trust, such as well-known telcos or mobile wallets. This allows applications that trust each other to benefit from an open and interoperable identity protocol while retaining control of their UX and performance. For example, a mobile wallet will now be able to verify phone numbers on Celo using any method of choice (i.e. secret code, magic link, SIM card) while also optimizing success rates in regions that are most critical for its specific market strategy.
In addition to FederatedAttestations.sol, release 8 includes updates to Escrow.sol to allow escrowed payments to be gatekeeped by the same 'trusted' issuer logic described above (see this design doc for more info)
Finally, release 8 adds a new OdisPayments.sol contract to which future payments for ODIS quota will be directed. ODIS is a distributed system consisting of 7 'signers' each possessing a partial share of a BLS private key (see the docs for more info). These signers accept requests to sign blinded messages according to a rate limit determined by the request type. In both the original identity protocol and the new Federated Attestations protocol phone numbers are signed by ODIS and hashed before they are recorded on-chain to preserve user privacy. The goal of ODIS's rate limit is to impose a cost on querying phone number identifiers so that reading phone numbers from the blockchain in large quantities is prohibitively expensive. While the original ODIS rate limit imposed this cost by calculating quota as a function of on-chain transaction history, the new rate limit will impose this cost by requiring direct payments to a smart contract. This change has been made in order to make ODIS's privacy guarantees more explicit, and is enabled by the fact that most ODIS requests will now be routed through issuer servers as part of the Federated Attestations protocol. (see this PR for more details)
Contract Name | Old | New |
---|---|---|
Escrow |
1.1.1.2 | 1.2.0.0 |
FederatedAttestations |
0.0.0.0 | 1.1.0.0 |
UsingRegistryV2 |
1.0.0.0 | 1.1.1.0 |
UsingRegistryV2BackwardsCompatible |
0.0.0.0 | 1.1.0.0 |
OdisPayments |
0.0.0.0 | 1.1.0.0 |
Published by m-chrzan over 2 years ago
This is the seventh release of the Celo Core Contracts. It follows the release process per the docs.
OpenZeppelin Core Contracts Release 7 Audit: Part 1, Part 2
Release 7 gives validators the option to delegate a portion of their epoch
payments, provides some modifications to stable token related contracts to
simplifying deployments of new stable tokens, provides a safer way of interacting
with LockedGold pending withdrawals on-chain (paving the way for liquid staking
derivatives), and adds an extra sanity check in the Exchange.
This change allows validators to specify an address that will receive a fraction
of each of their epoch payments, allowing e.g. regular donations of part of
their payments.
Fixed Exchange.sol reverting on deployment due to expecting sortedOracles report on null address (#8334)
Remove oracle check (#9367)
These two changes will allow a future stable token deployment flow that is much
more convenient and faster than what is necessary with the current release
process. Currently, several separate governance proposals need to pass, each
executing after the others, leading to a new stable token requiring several
weeks from first proposal to on-chain activation. With careful changes to sanity
checks, this could be reduced to needing a single governance proposal.
Previously, the only way to access an account's pending withdrawals was by
calling the getPendingWithdrawals
function, which would return the array of
all pending withdrawals for that account. This makes it difficult to implement
onchain LockedGold accounts governed by a smart contract -- if any party is able
to create new pending withdrawals, once the pending withdrawals array gets big
enough, getPendingWithdrawals
would revert every time due to the gas cost of
reading the entire array into memory.
This PR introduces a new getPendingWithdrawal
function that looks up a single
pending withdrawal given a particular index.
A simple sanity check that ensures the Exchange's spread, which is meant to be
a percentage, is less than or equal to 100%.
Contract Name | Old | New |
---|---|---|
Accounts |
1.1.3.0 | 1.1.4.0 |
LockedGold |
1.1.1.2 | 1.1.2.0 |
Validators |
1.2.0.2 | 1.2.0.3 |
Exchange |
1.1.1.0 | 1.2.0.0 |
ExchangeBRL |
1.1.1.0 | 1.2.0.0 |
ExchangeEUR |
1.1.1.0 | 1.2.0.0 |
GrandaMento |
1.1.0.0 | 1.1.0.1 |
Reserve |
1.1.2.1 | 1.1.2.2 |
Published by aaronmgdr over 2 years ago
Crypto functions and utils that were move out of the @celo/utils package to reduce bundle size
an SDK for creating PIN/password encrypted user data backups as used by PEAR
See Upgrade Guide
All Phone number and Country related functions have been removed. Please import from @celo/phone-utils instead
comment encryption, bls and mneumonic functions moved to @celo/cryptographic-utils
Connection
rather than a kit
as an argument.MiniContractKit
a minimal version of contract kit with acess to only a few contracts and wrappers
Published by m-chrzan over 2 years ago
This is the seventh release of the Celo Core Contracts. It follows the release process per the docs.
OpenZeppelin Core Contracts Release 7 Audit (to be published soon)
TODO
TODO
Published by m-chrzan over 2 years ago
This is the sixth release of the Celo Core Contracts. It follows the release process per the docs.
OpenZeppelin Core Contracts Release 6 Audit (to be published soon)
Release 6 allows wallet and other application developers easier access to off-chain storage, fixes a small bug in the LockedGold contract, and cleans up an unnecessary function in Solidity libraries.
CIP8 was originally defined on top of CIP3. This meant that two network hops were necessary to access the CIP8 storage URL (first request the CIP3 URL from the Celo blockchain, then look up the CIP3 data, including the CIP8 URL, over HTTP based on that URL). Modifying the CIP8 URL also meant modifying and reuploading the entire CIP3 file. PR 8360 adds direct access to multiple CIP8 URLs in the Accounts smart contract, making it easier to access and modify these endpoints.
Slashing rewards are denominated in locked CELO (managed by the LockedGold smart contract). Locked CELO can only be managed by accounts on the Accounts smart contract. Previously there was no check ensuring that a slashing reporter had an account, thus the locked CELO credited as a reporter reward could have ended up indefinitely unusable.
Core Celo contracts implement a getVersionNumber()
function, as per the Celo Smart Contracts release process. This function should only be implemented on concrete, non-library smart contracts deployed on-chain, but was previously also implemented on several library contracts. The unnecessary function was removed from these libraries, forcing PATCH version increases on several contracts:
Contract Name | Old | New |
---|---|---|
Accounts |
1.1.2.0 | 1.1.3.0 |
Attestations |
1.1.1.1 | 1.1.1.2 |
Election |
1.1.2.0 | 1.1.2.1 |
Escrow |
1.1.1.1 | 1.1.1.2 |
Governance |
1.2.1.0 | 1.2.1.1 |
LockedGold |
1.1.1.1 | 1.1.1.2 |
SortedOracles |
1.1.2.0 | 1.1.2.1 |
Validators |
1.2.0.1 | 1.2.0.2 |
Published by eelanagaraj almost 3 years ago
This is a backwards-compatible release that includes the following features/fixes:
v1.5.0
to 1.4.0-
, this can in rare cases cause a one-time dip in automatic resends for in-progress attestations.7d47b0b5fa3b80165091d1e0c1732503cc83b618
de7d9a9c071cd20d86b164ae1da0b1d8f15d8b4e
cf48bd7dd467fc86196ea302c50683207be04329
Published by eelanagaraj about 3 years ago
This is a backwards-compatible release that includes the following features/fixes:
e9cc99923c75bcff14310c6fa2269483dcd283fd
ef0a683f708455b5fe2a120c929feb3ed4d32b95
Published by yorhodes about 3 years ago
This is the fifth release of the Celo Core Contracts. It follows the release process per the docs.
OpenZeppelin Core Contracts Release 5 Audit
Release 5 addresses a community demand for large volume exchanges which aren't suited for Mento or OTC. It also fixes a small bug in the Validators contract which only has implications for newborn networks (discovered on our private testnets) and adds an additional registry utility for contract developer usage.
Granda Mento is a mechanism to facilitate large CELO <-> stable token (e.g. cXXX) exchanges that aren't suitable via Mento or OTC. GrandaMento is a new contract that can exchange CELO <-> stable token for any stable token Governance explicitly enables. Exchanges via this contract must be approved by a multisig and can be vetoed by the Governance contract. For more detailed information, please reference CIP-0038.
updateMembershipHistory
in Validators.sol correct if epoch number is 0 #8060This change fixes a bug in the Validators contract that has not appeared in a production environment. It is motivated by cLabs usage of mycelo testnets that apply migration results as part of genesis generation. A validator's membership history is currently not updated when there is are no history entries (ie when epoch == 0).
This new contract is an alternative to UsingRegistry that contains no storage variables for more lightweight inheritance.
Contract Name | Old | New |
---|---|---|
GrandaMento |
- | 1.1.0.0 |
StableToken |
1.2.0.0 | 1.2.0.1 |
StableTokenEUR |
1.1.0.0 | 1.1.0.1 |
Validators |
1.2.0.0 | 1.2.0.1 |
Published by codyborn over 3 years ago
77a392216d4927e85ce4b683508fc0539aa92a34
Published by codyborn over 3 years ago
Fixes a filtering bug in Nexmo queries.
6ca848629957cac7bd882d0e361a29620b2e03a1
Published by medhakothari over 3 years ago
This release was published on July 8th, 2021 and includes commits from 125f98da65f9b8161af524d183b7da70b96e2a07
to 9207df90be8c0ae3b377914156ce600eec08d32a
inclusive.
Published by codyborn over 3 years ago
Support a US toll-free number registration in Nexmo. Add new information to /status endpoint that helps correlate SMS Provider success rates.
ab46eecf3b13793580cabac2bb80a425cb10f9e3
f632e799a97cbcf803683a1da87dc63c912f5e9a
Published by yorhodes over 3 years ago
This is the fourth release of the Celo Core Contracts. It follows the release process per the docs.
Certora Core Contracts Release 4 Audit
OpenZeppelin Core Contracts Release 4 Audit
Release 4 addresses feedback the community has provided on the identity abstraction implemented in the core contracts. It also makes way for various throughput optimizations and improvements in light of recent network throttling as a result of new user influx.
The Accounts contract houses a general account abstraction that currently serves several purposes including identity in the Proof-of-Stake system (validator, voter, and attestation signers) and storing profile information such as a Data Encryption Key for use with off-chain signed metadata. The authorization of signer keys is a useful method to authenticate the account owner for specific roles without requiring the most-privileged account key to come online. This change adds a generalized segmentation of domains for account authorizations, giving Celo stakeholders more flexibility in their custody setup.
During periods of heavy onboarding traffic, we have observed the block gas limit being the limiting factor in the number of users we can onboard per block. This is primarily because we subsidize the costs of user onboarding and phone number verification through smart contract wallets, and subsequently need to deploy a new contract per user. This change employs "minimal" proxies to greatly reduce the gas costs of performing this onboarding subsidization and contract deployment.
An account's pending votes must be activated after an epoch has passed. For end users, this is an unideal experience. This change allows a non-trusted account to activate pending votes on behalf of another account, eliminating the need for 2 transactions over the course of 2 epochs. The recipient validator group, for example, has a direct incentive to perform this activation.
During recent governance activities, some users voted and were surprised that they could not unlock their CELO. This is to prevent voting on proposals that result in depreciation of CELO. Previously there was no option to revoke votes for an account so that locked CELO can be released. This change adds a revokeVotes
method which revokes all Referendum votes for an account and allows them to begin the unlock period.
The Celo blockchain launched with the native token called "Celo Gold" (symbol "cGLD"), but to avoid confusion (since the token has nothing to do with physical gold), after a community proposal and vote (CGP 4), it was renamed to "Celo native asset" (ticker symbol CELO). This change updates the ERC-20 contract's name and symbol constants.
To support phone numbers (or other future identifiers) as a factor in account recovery, a contract needs to act as a proxy for any address considered verified. This change adds an IdentityProxy
that can be used by the owner of an identifier to make arbitrary calls, determining ownership by the on-chain heuristic as defined in the Attestations
contract. It also adds an IdentityProxyHub
for deploying instances with CREATE2
, delaying deployment until the proxy is needed during account recovery and avoiding additional throughput congestion during heavy onboarding traffic.
The MetaTransactionWallet will have an owner settable guardian address. This address has the ability to change the wallet's signer. This feature is in support of account recovery features for user-facing wallets like Valora.
Contract Name | Old | New |
---|---|---|
Accounts |
1.1.1.1 | 1.1.2.0 |
Election |
1.1.1.0 | 1.1.2.0 |
Governance |
1.2.0.2 | 1.2.1.0 |
GoldToken |
1.1.1.0 | 1.1.1.1 |
Reserve |
1.1.2.0 | 1.1.2.1 |
Contract Name | Old | New |
---|---|---|
MetaTransactionWalletDeployer |
1.1.0.0 | 1.1.0.1 |
MetaTransactionWallet |
1.1.0.1 | 1.1.1.0 |
Published by gastonponti over 3 years ago
This release was published on April 22nd, 2021 and includes commits till 125f98da65f9b8161af524d183b7da70b96e2a07 inclusive
Published by gastonponti over 3 years ago
This release was published on April 22nd, 2021 and includes commits till c78ae096d114d88107cc206afcc5150d0f5b6671 inclusive
Published by medhakothari over 3 years ago
This release was published on March 22nd, 2021 and includes commits from 64e618b9b856073305dd5748fc04fc772ff72714
to 7e7a7913e1dbd4ce72ddc6384a054138c8ec32e8
inclusive.
rewards:show
- #7325
getReserveGoldBalance
, dont alias itself - #7334
governance:approver
information - #7478
Published by medhakothari over 3 years ago
This release was published on February 17th, 2021 and includes commits from 23b12644eda957ef87530845ff062e9f02358dd4
to f79c14fd5dfb96249cd28d4fcc6287a088eaacd5
inclusive.
releasegold:show
should succeed w/o account registration - #7092
releasegold:show
- #7098
multisig:transfer
- #6982
Published by medhakothari over 3 years ago
This release was published on February 17th, 2021 and includes commits from 2f5b795a601375d41b67ca0afe47107f8448ff50
to ffcf304361ae18cd38d4bc45b635a9043bb55c7a
inclusive.
releasegold:show
- #6608
identity:current-attestation-services
- #6806