convert CurrentAnswerInterface to int256 #1280
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
se3000
force-pushed
the
features/current-answer-int256
branch
from
3f438ed to
89d809a
Compare
coventry
reviewed
May 29, 2019
| { | ||
| // solium-disable-next-line zeppelin/no-arithmetic-operations | ||
| int256 c = _a + _b; // signed integers are not supported by SafeMath | ||
| require(c >= _a, "SafeMath: addition overflow"); |
There was a problem hiding this comment.
This condition should not hold, if _b is negative. I think it's necessary to enumerate the cases for the possible signs of _a and _b, or something similar to that.
There should probably be tests for correct behavior and halting in the four cases, too.
There was a problem hiding this comment.
I suppose there are only two cases, actually: _b non-negative, and _b negative.
- will move to OpenZeppelin version once we are compatible with Solidity v0.5
coventry
approved these changes
May 29, 2019
asoliman92
pushed a commit
that referenced
this pull request
Aug 28, 2024
## Motivation Currently all USDC token transfers occur using Burn/Mint with calls to Circle's CCTP system for cross-chain transfers. Certain chains in CCIP have non-canonical USDC deployed and want to integrate the ability to use CCIP as a canonical bridge whereby canonical-USDC is locked on the source-chain and then minted on the destination chain. Then at a later date, when circle decides to add that chain to CCTP, the non-canonical USDC will be converted into canonical by burning the locked-tokens on the source-chain. To accomplish this, the token pool needs to be capable of identifying when tokens should be burned/minted with CCTP, or if they should use regular lock-release, and act accordingly. ## Solution `USDCTokenPool.sol` was been modified into a new file to allow for two different mechanisms to be used simultaneously. The primary mechanism, which is opt-out, and the secondary-mechanism which is opt in. These mechanisms are configured on a per-chain-selector basis, and must be manually enabled. In this implementation CCTP is the primary mechanism, and Lock/Release is the alternative mechanism. There are two new files 1. `HybridLockReleaseUSDCTokenPool.sol`, The actual implementation of the hybrid pool structure. 3. `USDCBridgeMigrator.sol`, which contains the logic necessary to conform to [Circle's migration policy guide](https://github.com/circlefin/stablecoin-evm/blob/master/doc/bridged_USDC_standard.md#transferring-the-roles-to-circle)
asoliman92
pushed a commit
that referenced
this pull request
Aug 28, 2024
## Motivation Currently all USDC token transfers occur using Burn/Mint with calls to Circle's CCTP system for cross-chain transfers. Certain chains in CCIP have non-canonical USDC deployed and want to integrate the ability to use CCIP as a canonical bridge whereby canonical-USDC is locked on the source-chain and then minted on the destination chain. Then at a later date, when circle decides to add that chain to CCTP, the non-canonical USDC will be converted into canonical by burning the locked-tokens on the source-chain. To accomplish this, the token pool needs to be capable of identifying when tokens should be burned/minted with CCTP, or if they should use regular lock-release, and act accordingly. ## Solution `USDCTokenPool.sol` was been modified into a new file to allow for two different mechanisms to be used simultaneously. The primary mechanism, which is opt-out, and the secondary-mechanism which is opt in. These mechanisms are configured on a per-chain-selector basis, and must be manually enabled. In this implementation CCTP is the primary mechanism, and Lock/Release is the alternative mechanism. There are two new files 1. `HybridLockReleaseUSDCTokenPool.sol`, The actual implementation of the hybrid pool structure. 3. `USDCBridgeMigrator.sol`, which contains the logic necessary to conform to [Circle's migration policy guide](https://github.com/circlefin/stablecoin-evm/blob/master/doc/bridged_USDC_standard.md#transferring-the-roles-to-circle)
asoliman92
pushed a commit
that referenced
this pull request
Aug 28, 2024
## Motivation Currently all USDC token transfers occur using Burn/Mint with calls to Circle's CCTP system for cross-chain transfers. Certain chains in CCIP have non-canonical USDC deployed and want to integrate the ability to use CCIP as a canonical bridge whereby canonical-USDC is locked on the source-chain and then minted on the destination chain. Then at a later date, when circle decides to add that chain to CCTP, the non-canonical USDC will be converted into canonical by burning the locked-tokens on the source-chain. To accomplish this, the token pool needs to be capable of identifying when tokens should be burned/minted with CCTP, or if they should use regular lock-release, and act accordingly. ## Solution `USDCTokenPool.sol` was been modified into a new file to allow for two different mechanisms to be used simultaneously. The primary mechanism, which is opt-out, and the secondary-mechanism which is opt in. These mechanisms are configured on a per-chain-selector basis, and must be manually enabled. In this implementation CCTP is the primary mechanism, and Lock/Release is the alternative mechanism. There are two new files 1. `HybridLockReleaseUSDCTokenPool.sol`, The actual implementation of the hybrid pool structure. 3. `USDCBridgeMigrator.sol`, which contains the logic necessary to conform to [Circle's migration policy guide](https://github.com/circlefin/stablecoin-evm/blob/master/doc/bridged_USDC_standard.md#transferring-the-roles-to-circle)
asoliman92
pushed a commit
that referenced
this pull request
Aug 28, 2024
## Motivation Currently all USDC token transfers occur using Burn/Mint with calls to Circle's CCTP system for cross-chain transfers. Certain chains in CCIP have non-canonical USDC deployed and want to integrate the ability to use CCIP as a canonical bridge whereby canonical-USDC is locked on the source-chain and then minted on the destination chain. Then at a later date, when circle decides to add that chain to CCTP, the non-canonical USDC will be converted into canonical by burning the locked-tokens on the source-chain. To accomplish this, the token pool needs to be capable of identifying when tokens should be burned/minted with CCTP, or if they should use regular lock-release, and act accordingly. ## Solution `USDCTokenPool.sol` was been modified into a new file to allow for two different mechanisms to be used simultaneously. The primary mechanism, which is opt-out, and the secondary-mechanism which is opt in. These mechanisms are configured on a per-chain-selector basis, and must be manually enabled. In this implementation CCTP is the primary mechanism, and Lock/Release is the alternative mechanism. There are two new files 1. `HybridLockReleaseUSDCTokenPool.sol`, The actual implementation of the hybrid pool structure. 3. `USDCBridgeMigrator.sol`, which contains the logic necessary to conform to [Circle's migration policy guide](https://github.com/circlefin/stablecoin-evm/blob/master/doc/bridged_USDC_standard.md#transferring-the-roles-to-circle)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.