Skip to content

Commit

Permalink
GuardV3 public member
Browse files Browse the repository at this point in the history
  • Loading branch information
xiaoch05 committed Dec 27, 2023
1 parent 320d11e commit d305154
Show file tree
Hide file tree
Showing 6 changed files with 405 additions and 405 deletions.
4 changes: 2 additions & 2 deletions helix-contract/contracts/mapping-token/v3/GuardV3.sol
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,10 @@ import "../interfaces/IWToken.sol";
contract GuardV3 is GuardRegistryV3, Pausable {
using SafeMath for uint256;

mapping(uint256 => bytes32) deposits;
mapping(uint256 => bytes32) public deposits;

uint256 public maxUnclaimableTime;
mapping(address => bool) depositors;
mapping(address => bool) public depositors;
address public operator;

event TokenDeposit(address sender, uint256 id, uint256 timestamp, address token, address recipient, uint256 amount);
Expand Down
188 changes: 94 additions & 94 deletions helix-contract/flatten/xtoken-v3/GuardV3.sol
Original file line number Diff line number Diff line change
Expand Up @@ -19,15 +19,6 @@

pragma solidity ^0.8.17;

// File contracts/mapping-token/interfaces/IWToken.sol
// License-Identifier: MIT


interface IWToken {
function deposit() external payable;
function withdraw(uint wad) external;
}

// File @zeppelin-solidity/contracts/utils/[email protected]
// License-Identifier: MIT
// OpenZeppelin Contracts (last updated v4.7.0) (utils/Strings.sol)
Expand Down Expand Up @@ -617,6 +608,98 @@ contract GuardRegistryV3 {
}
}

// File contracts/mapping-token/interfaces/IWToken.sol
// License-Identifier: MIT


interface IWToken {
function deposit() external payable;
function withdraw(uint wad) external;
}

// File @zeppelin-solidity/contracts/token/ERC20/[email protected]
// License-Identifier: MIT
// OpenZeppelin Contracts (last updated v4.6.0) (token/ERC20/IERC20.sol)


/**
* @dev Interface of the ERC20 standard as defined in the EIP.
*/
interface IERC20 {
/**
* @dev Emitted when `value` tokens are moved from one account (`from`) to
* another (`to`).
*
* Note that `value` may be zero.
*/
event Transfer(address indexed from, address indexed to, uint256 value);

/**
* @dev Emitted when the allowance of a `spender` for an `owner` is set by
* a call to {approve}. `value` is the new allowance.
*/
event Approval(address indexed owner, address indexed spender, uint256 value);

/**
* @dev Returns the amount of tokens in existence.
*/
function totalSupply() external view returns (uint256);

/**
* @dev Returns the amount of tokens owned by `account`.
*/
function balanceOf(address account) external view returns (uint256);

/**
* @dev Moves `amount` tokens from the caller's account to `to`.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* Emits a {Transfer} event.
*/
function transfer(address to, uint256 amount) external returns (bool);

/**
* @dev Returns the remaining number of tokens that `spender` will be
* allowed to spend on behalf of `owner` through {transferFrom}. This is
* zero by default.
*
* This value changes when {approve} or {transferFrom} are called.
*/
function allowance(address owner, address spender) external view returns (uint256);

/**
* @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* IMPORTANT: Beware that changing an allowance with this method brings the risk
* that someone may use both the old and the new allowance by unfortunate
* transaction ordering. One possible solution to mitigate this race
* condition is to first reduce the spender's allowance to 0 and set the
* desired value afterwards:
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
*
* Emits an {Approval} event.
*/
function approve(address spender, uint256 amount) external returns (bool);

/**
* @dev Moves `amount` tokens from `from` to `to` using the
* allowance mechanism. `amount` is then deducted from the caller's
* allowance.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* Emits a {Transfer} event.
*/
function transferFrom(
address from,
address to,
uint256 amount
) external returns (bool);
}

// File @zeppelin-solidity/contracts/utils/[email protected]
// License-Identifier: MIT
// OpenZeppelin Contracts v4.4.1 (utils/Context.sol)
Expand Down Expand Up @@ -974,89 +1057,6 @@ library SafeMath {
}
}

// File @zeppelin-solidity/contracts/token/ERC20/[email protected]
// License-Identifier: MIT
// OpenZeppelin Contracts (last updated v4.6.0) (token/ERC20/IERC20.sol)


/**
* @dev Interface of the ERC20 standard as defined in the EIP.
*/
interface IERC20 {
/**
* @dev Emitted when `value` tokens are moved from one account (`from`) to
* another (`to`).
*
* Note that `value` may be zero.
*/
event Transfer(address indexed from, address indexed to, uint256 value);

/**
* @dev Emitted when the allowance of a `spender` for an `owner` is set by
* a call to {approve}. `value` is the new allowance.
*/
event Approval(address indexed owner, address indexed spender, uint256 value);

/**
* @dev Returns the amount of tokens in existence.
*/
function totalSupply() external view returns (uint256);

/**
* @dev Returns the amount of tokens owned by `account`.
*/
function balanceOf(address account) external view returns (uint256);

/**
* @dev Moves `amount` tokens from the caller's account to `to`.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* Emits a {Transfer} event.
*/
function transfer(address to, uint256 amount) external returns (bool);

/**
* @dev Returns the remaining number of tokens that `spender` will be
* allowed to spend on behalf of `owner` through {transferFrom}. This is
* zero by default.
*
* This value changes when {approve} or {transferFrom} are called.
*/
function allowance(address owner, address spender) external view returns (uint256);

/**
* @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* IMPORTANT: Beware that changing an allowance with this method brings the risk
* that someone may use both the old and the new allowance by unfortunate
* transaction ordering. One possible solution to mitigate this race
* condition is to first reduce the spender's allowance to 0 and set the
* desired value afterwards:
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
*
* Emits an {Approval} event.
*/
function approve(address spender, uint256 amount) external returns (bool);

/**
* @dev Moves `amount` tokens from `from` to `to` using the
* allowance mechanism. `amount` is then deducted from the caller's
* allowance.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* Emits a {Transfer} event.
*/
function transferFrom(
address from,
address to,
uint256 amount
) external returns (bool);
}

// File contracts/mapping-token/v3/GuardV3.sol
// License-Identifier: Apache-2.0

Expand All @@ -1068,10 +1068,10 @@ interface IERC20 {
contract GuardV3 is GuardRegistryV3, Pausable {
using SafeMath for uint256;

mapping(uint256 => bytes32) deposits;
mapping(uint256 => bytes32) public deposits;

uint256 public maxUnclaimableTime;
mapping(address => bool) depositors;
mapping(address => bool) public depositors;
address public operator;

event TokenDeposit(address sender, uint256 id, uint256 timestamp, address token, address recipient, uint256 amount);
Expand Down
2 changes: 1 addition & 1 deletion helix-contract/flatten/xtoken-v3/MsglineMessager.sol
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@
* '----------------' '----------------' '----------------' '----------------' '----------------' '
*
*
* 12/25/2023
* 12/26/2023
**/

pragma solidity ^0.8.17;
Expand Down
Loading

0 comments on commit d305154

Please sign in to comment.