# Integrating Allo2 in EasyRPGF I've been working on adding Allo2 to Easy RPGF and ran into a couple of issues that make it harder for developers to use the protocol: >TLDR; >- Remove the requirement of a Profile when creating Pools >- Ability to create many pools for a custom strategy ### 1. Creating a Pool requires a Registry Profile A Profile ID is required to create a pool. There's a function that checks if the ProfileID is owned by the wallet sending the transaction. This means it's not possible to create a "global" profile that could be reused for all EzAllo Pools. This is the only time the Profile is actually used in the Allo.sol contract (however, some strategies uses it as gating). It would make more sense if a profile is optional to create a pool. Creating a Profile requires this from the frontend: - Call Allo2 Registry and get profileById. How do we get the profile id to check? It's not clear but we can hash the users address together with a nonce. - Check if the connected wallet as a profile, if not show a UI and a button to create the profile. - Call create profile, wait for transaction to be mined, and fetch the profile again. This might not seem like much but it takes a significant amount of work to call these contracts, handle waiting for transactions, the logic checks in the UI, and build the components and messages to be displayed. The registry also encourages metadata and a name to be sent when creating a profile. To do this would add additional work of building a form for the data as well as the name and uploading this metadata to an IPFS provider before calling create profile. Also, I haven't seen any recommendations on how to structure the metadata. ### 2. Custom strategies can only contain one pool The logic for creating a pool for approved and custom strategies differ. For the approved strategies, the strategy contract is cloned (a gas effective way to deploy a contract). Creating custom strategies doesn't do this. This means that the custom strategy needs to be deployed by the EzRPGF round manager before the pool can be created. To get around this we can deploy a contract that clones the strategy and then calls the createPoolWithCustomStrategy function, but in my opinion the protocol should handle this for the developers. If a developer writes a popular strategy to be used by several platforms, it should be easy to create pools with it without requireing deployment of additional contracts. Another way would be to ask Allo2 team to add the EzRPGF contract to approved contracts, but if the contract is changed and re-deployed, it needs to be removed and added again. Do Allo2 support upgradeable strategies?