Skip to content

Latest commit

 

History

History
113 lines (89 loc) · 4.13 KB

README.md

File metadata and controls

113 lines (89 loc) · 4.13 KB
Raw

Aelin Subgraph

A Aelin subgraph for The Graph. Aelin is a fundraising protocol built on Ethereum.

Getting Started

Install the project dependencies by running npm install

Prerequisites: Node.js and npm installed, preferably LTS versions

Hosted Deployment

The deploy script simplifies the deployment process, allowing you to deploy to any network and repo.

  • Create a .env file in the root directory and set the GRAPH_ACCESS_TOKEN environment variable

  • Run npm run deploy:hosted:init with the --network and --repo arguments:

    e.g.: npm run deploy:hosted:init -- --network <network> --repo <repo>

Replace <network> with the desired network (e.g., goerli, mainnet, optimism, arbitrum, polygon) and <repo> with the desired repository name (e.g., user/repo).

Studio Deployment

The deploy script simplifies the deployment process, allowing you to deploy to any network and slug.

  • Create a .env file in the root directory and set the GRAPH_DEPLOY_KEY environment variable

  • Run npm run deploy:studio:init with the --network and --slug arguments:

    e.g.: npm run deploy:studio:init -- --network <network> --slug <slug>

Replace <network> with the desired network (e.g., mainnet, arbitrum) and <slug> with the desired subgraph slug (e.g., your-subgraph-slug).

Notifications

Notifications are a powerful feature that will allow Aelin to create a communication chanel with users in a reliable way. All notifications are design with a goal in mind: little-to-none work should be done on the client-side to transform chain data.

Rendering

Notifications are created in advanced, this means that the client will have to decide if a notification should be rendered depending on triggerStart and triggerEnd fields.
It's important to mention that all(*) notifications will be removed from the subgraph at certain point and therefore wont be possible to query them again from that point.
Some notifications might be stored forever depending on the context and certain conditions, ie: a pool is created but no one invests in it and no deal is created. As a consequence no event will be emitted to remove InvestmentWindowAlert and InvestmentWindowEnded

Filtering

Notifications can be easily filtered by target and type, for instance:
If a user has invested in PoolA, when all notifications from PoolA are pulled from the subgraph, the client will have to show only those relevant for the user, and in this case, since the user is (only) an investor, then the client should filter by target: Investor

Entity Fields


NameTypeDescription
idIDaddress - NotificationType
address could be a poolAddress, dealAddress, or a userAddress
messageStringThe notification message
type 
enum NotificationType {
	InvestmentWindowAlert
	InvestmentWindowEnded
	DealProposed
	HolderSet
	SponsorFeesReady
	VestingCliffBegun
	WithdrawUnredeemed
	DealTokensVestingBegun
	AllDealTokensVested
}
Depending on the type field, the client-side will
decide if the message needs to be adapted or changed.
target 
enum NotificationTarget {
	Investor
	Sponsor
	Holder
}
Since all notifications types and targets from a certain Pool
will be queried from the subgraph, the client will need a
way to filter them depending on the user type
(investor, sponsor, holder)
triggerStartBigIntNotification should be visible to the client only if the current
time has passed triggerStart
triggerEndBigIntNotification should be NOT be visible to the client if the current
time has passed triggerEnd
poolPoolCreatedContain all the information of the pool related to the notification