aavegotchi / aavegotchi-contracts Goto Github PK

Maybe possible to make this broader so it can apply to all types of items, not just wearables?

Withdrawing Aavegotchis & Portals from Matic

Here is information needed for user interfaces for bridging Aavegotchis and portals:

This is the function to call on the AavegotchiDiamond to lock and withdraw Aavegotchis and portals on Matic Network:
function withdrawAavegotchiBatch(uint256[] calldata _tokenIds) external. Call that contract function on Matic Network.

Get the transaction hash for that transaction.

Call the exitBatchERC721(txHash: string, options?: SendOptions) from maticjs, from their MaticPOSClient class. Note that this function is not in their documentation but it is in their source code. This function gets called on Ethereum on Matic's standard RootChainManger contract.

Withdrawing Aavegotchi Items from Matic

This is the function to call on the AavegotchiDiamond to withdraw Aavegotchis items on Matic Network:
function withdrawItemsBatch(uint256[] calldata _ids, uint256[] calldata _values) external. Call that contract function on Matic Network.

Call the exitBatchERC1155(txHash: string, options?: SendOptions) from maticjs, from their MaticPOSClient class. Note that this function is not in their documentation but it is in their source code. This function gets called on Ethereum on Matic's standard RootChainManger contract.

Right now the hand classes do not have a single SVG class to target them all, just individual ones. It's necessary to have a single class that targets all hand positions together so they can be animated up/down alongside the body.

Initially I believe we decided to restrict useConsumable to only one item, but to help users save gas it makes more sense to allow multiple items. So let's change it back to taking an array of IDs and quantities.

Let's make this change as an upgrade to the currently deployed AavegotchiDiamond contract: 0xDdC64462aEBA340cBE52E2B64eef20D0B23B5126.

We are still using the old LEND Svgs but those will not be supported in launch. We should switch to the Aave Svg and collateral ASAP.

Uni collateral eyes need to be updated

Fixed: a0ac188

Matic supports meta transactions (gasless transactions) and suggests we use Biconomy as a service provider. We will need to make some small changes to our smart contracts to enable these.

https://docs.biconomy.io/tutorials/native-meta-transactions

https://github.com/bcnmy/metatx-standard

After creating a few listings, calling getERC1155Listings with params "0", "listed", 20 results in 20 listings, even though there should only be 2 unique listings.

All of the shop wearables have a ghstPrice field that shows their price in the store. Since raffle wearables were not sold in the store, their price is 0. However, it may be beneficial to assign an estimated GHST price to the raffle wearables, so we can help estimate how much an Aavegotchi is worthy (based on how many wearable it is holding)

Currently we are not returning whether or not an Aavegotchi is locked in getAavegotchi(). This is necessary information for the frontend UI so we can restrict certain functions while the Aavegotchi is locked.

To do: Return locked as a bool, and if locked=true then return the unlockTime. If not locked, can just return 0 for unlockTime.

Should be gotchi-primary-mouth, not gotchi-primary mouth

We should limit the number of portals that a user can portal in one transaction, to prevent a large user from buying them all in one go. 50 would be a good number.

Currently we are not returning the final calculated kinship score in the getAavegotchi() function. It would be nice to return it.

I think we need to implement the following interface from the ERC721 standard so that services like OpenSea can interact with the Aavegotchi's metadata:

/// @title ERC-721 Non-Fungible Token Standard, optional metadata extension
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x5b5e139f.
interface ERC721Metadata /* is ERC721 */ {
    /// @notice A descriptive name for a collection of NFTs in this contract
    function name() external view returns (string _name);

    /// @notice An abbreviated name for NFTs in this contract
    function symbol() external view returns (string _symbol);

    /// @notice A distinct Uniform Resource Identifier (URI) for a given asset.
    /// @dev Throws if `_tokenId` is not a valid NFT. URIs are defined in RFC
    ///  3986. The URI may point to a JSON file that conforms to the "ERC721
    ///  Metadata JSON Schema".
    function tokenURI(uint256 _tokenId) external view returns (string);
}

@cinnabarhorse What should be the baseUri value used by tokenURI? Could be https://aavegotchi.com/metadata/aavegotchis/

The value of name could be Aavegotchi. What should the abbreviated name symbol be? "Gotchi" or "AGotchi" or "AGI"

We discussed locking Aavegotchis when they are listed for sale, and unlocking when the listing is removed. This should be implemented before launch.

We'll use this for day-to-day operational functions. After creating the modifier, please add it to:

grantExperience() and
updateItemMaxQuantity()

Currently rarity score is calculated from 0-100. It should actually only be from 0-99.

To fix this, we need to update the traits to only range from 0-99, and then update how BRS is calculated, using the following formula:

x < 50 : 100 - x
x >= 50: x+1

We can calculate the randomNumber on the fly, so there's no need to spend the extra gas to store it in openPortal().

Currently the value of numericTraits is unconverted int256, not an easily-readable array. Perhaps vit would be easier for developers if numericTraits were returned as a uint8 array, not an int256 number (but it can still be stored in memory as the int256)

Most hand wearables look fine in both hands, but some (like the REKT sign) only looks good in the left hand. So we should handle left and right hands separately when adding the items.

In addition to returning its current level, we can also return how much XP the aavegotchi has, and how much it needs until the next level

Some items like XP potions have a fixed quantity to begin with, but could be periodically "refilled" by increasing the maxAmount. This could be a good DAO function.

An Aavegotchi should be unlocked after a successful transfer. Otherwise we will have a lot of locked Aavegotchis and a potentially bad UX.

We need to display the Aavegotchi's rarity score on the frontend after it equips wearables. We can use the modifiedRarityScore() function and return this in getAavegotchi().

getAavegotchi() returns the Aavegotchi's randomNumber using

aavegotchiInfo_.randomNumber = s.aavegotchis[_tokenId].randomNumber

but it should probably be:
LibVrf.getBatchRandomNumber(s.aavegotchis[tokenId].batchId) because the random number comes from the batch number now.

The quantity in the ERC1155 listing is not being updated after it has been executed. The seller's balance is lowered and the buyer's balanced is increased, but the listing is not updated.

You can see the darker color should be on the outside, and lighter on the inside, but it appears to be reversed

Owner only owns one wearable but can equip it twice. Fix this.

Currently the user needs to wait 12 hours after the Aavegotchi has been claimed from the Portal for the interact() to increase Kinship. It would be nice if the player could interact once with the Aavegotchi to increase Kinship immediately after it is claimed from the Portal.

Currently we can only call interact() for one gotchi at a time. This prevents us from creating "gotchi walker" roles. It would be great if interact() took an array of tokenIds instead of just one.

This can be done as an upgrade on the current deployed Aavegotchi Diamond 0xDdC64462aEBA340cBE52E2B64eef20D0B23B5126 , if possible.

Currently there are no functions that allow reading listings from a specific user for ERC721s. We should implement these to aid with the frontend UI

Right now the portal opening is set to use 1 LINK per call. It would be better if it were set to 0.001 so we would not need to constantly use the faucet.

getItems() and all the other item functions are still returning traitModifiers as uints instead of int8 arrays. Would be better for developers if they were arrays.

Need to finalize the calculation of experience and levels before Mainnet deployment

In the SvgFacet we are adding some additional styles to show hands down and open. This breaks the styles at the top of the svg tag.

We should render all of the styles before the rest of the SVG is rendered.

Right now the collateral modifier isn't included in the numericTraits of singlePortalAavegotchiTraits return. This should be fixed so the buyer knows exactly what the numeric traits of their Aavegotchi will be.

It's worth considering to add a description field to itemType so we can have all of the descriptions of items onchain. This would allow developers to easily replicate a marketplace later. Many NFTs have short onchain metadata.

Need a pet/front and back slot to display pets properly

Currently the erc1155 method transferFromParent() only implements a single token ID to transfer. Would be nice if it could be extended to implement a batchTransferFromParent() function similar to below. Not urgent though.

  function batchTransferFromParent(
        address _fromContract,
        uint256 _fromTokenId,
        address _to,
        uint256[] _ids,
        uint256[] _values
    ) external

Since VRF is much cheaper on Matic we can strip out the Ritual and go back to one portal one VRF call. I've already made good progress. Please check the changes.

Don't show cancelled and sold portals in the getERC721Listings function