1. Update from master is needed
2. db/migrations/2000000000000-Views.js should be adjusted (see the related tutorial at: https://github.com/Lezek123/orion/blob/user-accounts/docs/developer-guide/tutorials/entity-visibility.md), mainly:
   • All new entities related to excluded channels should be hidden, ie.:

     // db/migrations/2000000000000-Views.js
     // ...
         nft_activity: [`EXISTS(SELECT 1 FROM "event" WHERE "id"="event_id")`],
         token: [`EXISTS(SELECT 1 FROM "channel" WHERE "id"="channel_id")`],
         revenue_share: [`EXISTS(SELECT 1 FROM "token" WHERE "id"="token_id")`],
         benefit: [`EXISTS(SELECT 1 FROM "token" WHERE "id"="token_id")`],
         // ...and so on, there should basically be an entry for each new entity
     // ...

   • To avoid a situation in which a video which is set as Token.trailerVideo and then excluded causes errors (because in this case the video won't exist in the public schema so querying Token.trailerVideo will throw an error) you should either create a view which overrides this field (Token.trailerVideo) to NULL if the video doesn't exist (is excluded) or introduce a new entity like TrailerVideo such that TailerVideo has 1-to-1 relationship with video and token. You would be able to more easily exclude it in this case, ie.:

     // db/migrations/2000000000000-Views.js
     // ...
         trailer_video: [
             `EXISTS(SELECT 1 FROM "token" WHERE "id"="token_id")`,
             `EXISTS(SELECT 1 FROM "video" WHERE "id="video_id")`
         ],
     // ...

3. It's difficult to retrieve the current sale associated with a given token, because Token.sale is a list of all sales. I suggest adding a field like Token.currentSale (or make Token.status an union with TokenStatusSale variant that would point to the current one). The same is true for AMMs and revenue splits.
4. Token should have a field like lastTransactionPrice, because in many places in the current designs there is a JOY value associated with each token.
   Actually this value can easily be manipulated if the issuer creates a sale and just buys from themselves, so perhaps the designs should be adjusted instead (?) CC: @bedeho
5. A query is needed that returns total portfolio value of a given member:
   • Liquid tokens value: aggregation like SUM(tokenAccount.transferrableAmount * token.lastTransactionPrice) for all owned tokens
   • Total tokens value: aggregation like SUM(tokenAccount.totalAmount * token.lastTransactionPrice) for all owned tokens
6. A query / field is needed that returns total transaction volume of a given token:
   • SUM(sale.tokensSold * sale.unitPrice) for all token's sales + SUM(ammTransaction.pricePaid) for all token's amm transactions.
     Actually I'm not sure if this stat is worth displaying on the token page, since it can be very easily manipulated CC @bedeho
7. AmmCurve should have termsAndConditions (same as Sale) according to the designs
8. Notifications: New events need to be introduced in schema/events.graphql to facilitate new kinds of notifications:
   • Token holder notifications:
     • Upcoming revenue split
     • Revenue split started
     • Revenue split ended
     • AMM started
     • Sale started
   • Channel follower notifications:
     • Token issued
     • Token sale initialized
   • Token issuer:
     • Sale eneded
     • Someone bought tokens on sale
     • Someone bought / sold tokens on AMM
     • Rev. Split has ended
       The exact schema for those notifications should probably be discussed with the Atlas team (CC: @attemka @drillprop @WRadoslaw)

Besides the issues pointed out in the new comments, there are still some unresolved points from the list provided as part of the 1st review (ie. #99 (review)), like points 4. - 9. (although I realize some of them require external input)