-
Notifications
You must be signed in to change notification settings - Fork 90
Design and implement multi-chain MembershipNFT support (deferred area) #275
Copy link
Copy link
Closed
Labels
GrantFox OSSGrantFox Open Source Sponsorship program tagGrantFox Open Source Sponsorship program tagMaybe RewardedIssue may qualify for a reward upon successful completion per campaign rulesIssue may qualify for a reward upon successful completion per campaign rulesOfficial Campaign | FWC26Official FWC26 campaign issue — eligible for campaign scoring and rewardsOfficial FWC26 campaign issue — eligible for campaign scoring and rewardsexpertExpert difficulty tasks requiring deep expertise and architectural decision-makingExpert difficulty tasks requiring deep expertise and architectural decision-makingfeatureNew feature, enhancement, or functional additionNew feature, enhancement, or functional addition
Description
Activity
Metadata
Metadata
Assignees
Labels
GrantFox OSSGrantFox Open Source Sponsorship program tagGrantFox Open Source Sponsorship program tagMaybe RewardedIssue may qualify for a reward upon successful completion per campaign rulesIssue may qualify for a reward upon successful completion per campaign rulesOfficial Campaign | FWC26Official FWC26 campaign issue — eligible for campaign scoring and rewardsOfficial FWC26 campaign issue — eligible for campaign scoring and rewardsexpertExpert difficulty tasks requiring deep expertise and architectural decision-makingExpert difficulty tasks requiring deep expertise and architectural decision-makingfeatureNew feature, enhancement, or functional additionNew feature, enhancement, or functional addition
Difficulty: Expert
Type: feature
Background
The README explicitly lists "Multi-chain support (current: EVM only)" as a deferred area, and notes that after deploying
MembershipNFT, operators set a singleMEMBERSHIP_NFT_ADDRESSandCHAIN_IDin.env— implying the current architecture assumes one contract on one chain.Problem
Communities that deploy
MembershipNFTon more than one EVM chain (e.g., mainnet + an L2) have no way to represent that in the data model or access API, since membership resolution is implicitly single-chain.Expected outcome
The data model and access API support multiple
(chainId, contractAddress)pairs per community, with membership resolution correctly disambiguating a wallet's memberships across chains, andpackages/contractsexposing per-chain ABI/address configuration instead of a single global address.Suggested implementation
memberships/communitiesPrisma schema to key membership records by(chainId, contractAddress, tokenId)rather than assuming a single global contract.packages/contractsto support a registry of{ chainId, address, abi }entries per community instead of a singleMEMBERSHIP_NFT_ADDRESS/CHAIN_IDpair.(chainId, contractAddress)./v1/memberships/:walletand/v1/access/checkto correctly aggregate or disambiguate memberships across chains for a single wallet..env.example, README, anddocs/openapi.jsonto reflect the new multi-chain configuration model, including a migration guide from the current single-chain setup.Acceptance criteria
MembershipNFTdeployments on more than one chain simultaneously.env.example/OpenAPI updatedLikely affected files/directories
packages/contracts/apps/access-api/prisma/schema.prismaapps/access-api/src/routes/.env.exampleREADME.md,docs/openapi.json