add example contracts for scout game #15
Conversation
| Attestation calldata attestation, | ||
| uint256 /*value*/ | ||
| ) internal override returns (bool) { | ||
| uint256 addedBalance = 10 * DECIMALS; |
There was a problem hiding this comment.
This would be a good place to add validations on who can attest
Example here
https://docs.attest.org/docs/tutorials/resolver-contracts#attester-resolver
| mapping(address => uint256) private _unclaimedBalances; | ||
|
|
||
| // Define a constant for 18 decimals | ||
| uint256 constant DECIMALS = 10 ** 18; |
There was a problem hiding this comment.
Would be preferable to read this value directly from the ERC20 token
| } | ||
|
|
||
| // Allow the sender to claim their balance as ERC20 tokens | ||
| function claimBalance(uint256 amount) public returns (bool) { |
There was a problem hiding this comment.
Why add an amount here? We could just make it claimBalance, and zero out the user's balance
| _pause(); | ||
| } | ||
|
|
||
| function unpause() public virtual { |
There was a problem hiding this comment.
I see alot of use of virtuals here, which mainly applies for overriding from inheriting contracts.
What is the use case for having virtuals everywhere?
| Attestation calldata attestation, | ||
| uint256 /*value*/ | ||
| ) internal override returns (bool) { | ||
| uint256 addedBalance = 10 * DECIMALS; |
There was a problem hiding this comment.
We will need some upgradeable way to evolve the balances calculation
| "Insufficient unclaimed balance" | ||
| ); | ||
| uint256 contractHolding = token.balanceOf(address(this)); | ||
| require(contractHolding >= amount, "Insufficient balance in contract"); |
There was a problem hiding this comment.
This raises an interesting product question of users having claimable balances that can't be claimed, something to look at
There was a problem hiding this comment.
Also, we could just build the revert logic into the transfer method of the ERC20
| token.transferFrom(msg.sender, address(this), amount); | ||
| } | ||
|
|
||
| function decodeValue( |
| } | ||
|
|
||
| // Deposit funds to the contract | ||
| function depositFunds(uint256 amount) public { |
There was a problem hiding this comment.
What is the use case for depositFunds?
| _mint(to, amount); | ||
| } | ||
|
|
||
| function mintForVesting(address to, uint256 amount) public virtual { |
There was a problem hiding this comment.
Wondering if this could be simplified, and the vesting contract hardcoded
| import "@openzeppelin/contracts/access/extensions/AccessControlEnumerable.sol"; | ||
| import "@openzeppelin/contracts/utils/Context.sol"; | ||
|
|
||
| contract ScoutToken is Context, AccessControlEnumerable, ERC20Pausable { |
There was a problem hiding this comment.
Noticing we don't have a max total supply here, that would be a useful safeguard to add
|
Adding some notes here from my overall understanding of mechanics ScoutGame protocol
ScoutGame vesting
ScoutGame token
One overall observation, I don't see any interfacing between the ERC1155 builder nft and this set of contracts, this would be good to understand Also, I see we have vesting in place for the protocol itself, wondering if there's a simpler way to handle this Finally, not seeing the pattern for upgrading the protocol itself, although I do see an updateScoutGameProtocol method in the vesting contract |
No description provided.