I actually not remember wich one window.ethereum or window.web3 is modern now.

Current state:

1. Client request all terminus address and admin_pool_id wich exists in blockchain.

https://dropper.moonstream.to/drops/terminus?blockchain=polygon

[
    {
        "terminus_address": "0x062BEc5e84289Da2CD6147E0e4DA402B33B8f796",
        "terminus_pool_id": 0,
        "blockchain": "polygon"
    }...
]

2. Client check if user has balanceOf that tokens(from blockchain in terminus address). And cache that information.
3. Client request drops/terminus/claims?blockchain=&terminus_pool_id=&terminus_address= endpoint and for each of combinations cache it and render to user all drops wich return thth endpoint.

After refactor:

contracts:

1. Get contracts endpoint play/contracts?blockchain=&contract_interface=Dropper it's return:
   extend option: if is_admin=True in query parameters then return only contracts to which user has admin access.

            id=result.id,
            blockchain=result.blockchain,
            address=result.address,
            title=result.title,
            description=result.description,
            image_uri=result.image_uri,

drops:

1. Whenever get admin/drops?blockchain=&contract=&claimNumber= and that return all drops wich user can edit in that dropper contract.
2. admin/drops/{dropper_claim_id}/claimants

• Implement contract service talks to contract to get URI
• Create getMetadata query hook that recieves URL and returns metadata

Need log in journal next kind of information:

1. claimant.address
2. transformed_amount,
3. claimant.amount
4. claimant.claim_id,
5. claimant.claim_block_deadline,
6. signature
7. signer server address

In cli all methods output as 1 line wich not readable.

• Claim type that allows minting of Terminus tokens.
• Terminus pool of tokens for which holders can create claims and set claim signers - admin workflow from Lootbox. (Currently only owner of Dropper contract can do this.)

When user connected his metamask, allow him to go to /inventory page and display there list of user items (lootboxes)

• (@Yhtiyar was this in contract or in the API?) service that gets list of users lootboxes
• useInventory hook that receives user address (and optionally chainId?), queries and stores data about lists of items player posses (item id)
• pages/Inventory page that lists items and renders items data; If item list is empty - implement CTA button to our discord

• Contract services that allow to open lootbox and take out loot (open/claim)
• Contract services that allow to get lootbox state
• useLootbox hook that queries lootbox state and has open and claim useMutations
• Component card that can be rendered with data provided from useLootbox and from Inventory page (props) and has button to open/claim lootbox

We was talk about multichain:

1. way support for different connection in different application(ports)
2. remove brownie and move to pure web3.py generated interface and be able create connection manager.

We need mappings of networks and add wrapper of multicall contract functionality

Instead of preventing users from claiming as part of a single drop multiple times, let us associate with each claim a request ID.

This will allow projects using the Dropper contract to use a single Drop (e.g. for experience points) in perpetuity while still retaining idempotence guarantees.

New modal component that shall guide user trough opening the lootbox.

Use and enhance hooks from #51 #50 to monitor state changes on the lootbox and render accordingly item state.

Refetch items in inventory after operation is complete

https://github.com/bugout-dev/engine/blob/fa55ac896a517b895408ff888aa29aa9ea8f5e8b/contracts/Lootbox.sol#L385-L389

sqlalchemy will try to parse the ENGINE_DB_URI even though you are not intended to use part of the engine which requires sql (as an example lootbox -h, or working with smart contract part)
as an external contributor it will make me think that I need to setup postgres with required table just to start working. This might make me quit the idea of contributing.

it will be easier if anybody can do source sample.env and directly start working and setup the vars when it is needed. (Requiring the env variable only when it is needed is the best way, but it might make a mess inside code)

setting that env variable to postgresql://localhost/mydb?user=other&password=secret will work

Engine part

supported tokens:

1. erc721
2. erc1155

realization

s3 path
{token_type}/{address}/{token_id}
each token have own storage with metadata

Create:
Add some form for select metadata.
It create S3 file.

Update.
Sopose take list of id and select metadata for them

Opensea part:

1. research opensea request to update metadata

• 1) Commit into DB after each /batchsign response
• 2) Reduce page size to 100.
• 3) Additionally, /refetch endpoint should be an asynchronous endpoint. We need to add jobs table to DB.
• 4) Add <job_id>\status for return to fronted current state of refetch signature task.
• 5) We need to cache claim type, and decimals for ERC20 claims.

take signAccessToken = function and release it as npm package that takes address string and duration argument and returns token

https://github.com/bugout-dev/lootbox/blob/1f378b056e258a4963dec3714fbcefe336c20d46/packages/moonstream-components/src/core/providers/Web3Provider/index.tsx#L48

Current frontend uses hardcoded values, make them env variables similarly how it is done in engine.moonstream.to

1. Currently with multiple drops you have 5(depends how many drops) area on are screen for upload white list in one moment. It pretty simple accidentally upload list to wrong drops.
2. We need add show the diff with ability edit, between what alredy in database and what will be added(requred diff endpoint on backend).
   proposal(Andrey): Maybe all actions with drops making on separate dops detail page.

setup deployment workflow to deploy to play.moonstream.to with production enviroment variables

• add to engine service method that sends metadata to the API
• Enchase useAdminClaim hook with setMetadata useMutate hook
• Add update metadata button to claims card component
• Create modal form that allows to fill in metadata and submit it

Players should be able to visit our supported games at https://play.moonstream.to.

One of the supported games should be Crypto Unicorns.

First view for players should be a view that allows them to stash UNIM and RBW into the Crypto Unicorns game.

Method to call is stashUNIMAndRBW.

A single Terminus contract + pool pair that determines addresses which can create drops on the contract and modify those drops in the API.

We should also add an endpoint like this:

curl -X POST /drops/claimants/diff -H "Content-Type: application/json" -d '[{"address": "<claimant_address>", "amount": <claimant_amount>}]'

This would calculate diff of request body list with the list of claimants in database.

It would display to the user the claimants who are in DB but not in list and the ones who are in list but not in DB.

• Check that columns are "address" and "amount".
• (Optional) check that addresses can be converted to checksum addresses

• Implement contract service talks to API to activate and deactivate claims
• Enhance useAdminClaim hook with useMutation's: activate , deactivate
• Implement buttons on claims cards that allow to call these functions

We want to be explicit for user whether data he entered will be saved or not .

Implement simple landing page similar to current engine.moonstream.to with prompt connect to metamask and four cards/links:

• Inventory: Link to "/inventory"
• Crafting [disabled/gray-out]
• Drops [disabled/gray-out]
• Profile [disabled/gray-out]

Make sure landing page has links to our Support/Discord, Github (can be in navbar/footer)

resolved with #68

There should be an API that returns:

• 1. Current UNIM balance of game bank contract
• 2. Current RBW balance of game bank contract
• 3. Amount of UNIM stashed into game bank (time series view)
• 4. Amount of RBW stashed into game bank (time series view)
• 5. Amount of UNIM unstashed from game bank (time series view)
• 6. Amount of RBW unstashed from game bank (time series view)
• 7. Number of players who stashed into game bank (time series view)
• 8. Number of players who unstashed from game bank (time series)
• 9. Average amount of UNIM stashed/unstashed per player (time series)
• 10. Average amount of RBW stashed/unstashed per player (time series)

Can we identify wallets who are stashing/unstashing directly from contract? Or the ones only using CU game mechanics?

this shall generalize with #45 of engine.moonstream.to

Before merging this - implement #51

• Implement contract service talks to contract to get URI
• Create getMetadata query hook that recieves URL and returns metadata

Terminus:

1. Contracts to wich user have access. Admin token or direct contract owner.

Fix cli showing only inactive dropps.
Add in conflict just skip.
Add claim_id in get_claims.