https://github.com/camaraproject/BlockchainPublicAddress/issues/72

WG

ONGOING

27/FEB/25: Agreed by WG to discuss this point within the next MetaRelease. Will be addressed after Issue 52 conclusion.

24/APR/25: Commented during the meeting we can begin to think about this topic. As commented by Georgios, good thing is that considering new Blockchain Networks do not modify the flow at all.

08/MAY/25: Pedro has not reviewed this topic yet. Georgios comments about an idea to manage that, by means of accomodating the new blockchain networks via the current defined model (as CAIP was analyzed time ago within the WG). Pedro likes this point of view and for implementation topics, in API Documentation it could be documented the relationship between current model and the CAIP model for the blockchains commented within the issue, just for underlying implementations that would rely on this model. To be checked in the next weeks.

22/MAY/25: Pedro will work next week in this approach and will share within the issue.
05/JUN/25:

1. Pedro introduced a "General Rule" proposal for blockchain networks, suggesting that all, except explicitly separated L1 networks, should follow an EVM-based model.

2. EVM Model Relationship with CAIP-2:

   • For EIP155, evm:<sub_id> will match eip155:<chain_id>.

   • For BIP122, evm:<sub_id> will be linked to the related bip122:<chain_id>.

3. Discussion centered on the feasibility of implementing this for Bitcoin. Georgios expressed concerns about how this approach would translate to Bitcoin, given its non-EVM nature. Pedro clarified that the general rule refers to networks that can follow an EVM-based model, and Bitcoin, as an L1, is an exception to be considered separately.

4. Georgios and Pedro will have an offline discussion to refine the approach, and model a way forward for this issue

https://github.com/camaraproject/BlockchainPublicAddress/issues/78

WG

ONGOING

24/APR/25: FollowUp of Issue 52. To work over it for the pending parts

08/MAY/25: After some investigation, Pedro indicates a possible way of doing this by means of an API. He needs to write down with the details. Basically, to cover this by an API solution it is needed that API provider is in the middle to be aware of the signature and store ir for later checking, that is for off-chain. Georgios is aligned with this. On-chain solution would imply Cross-Operator agreement to use/manage/implement a common wallet. Pedro and Georgios will work offline about that idea. No feedback received from Aleph Zero on this matter yet.

22/MAY/25: Both Georgios and Pedro have been investigating this topic offline. Not a solution found so far. They will be in touch, once a solution is found will be shared within the WG.

05/JUN/25:
It is agreed to move forward in a first step with the off-chain solution in order to cover basic engnaced feature. On-chain solution is more complex and may require more time in order to think how to handle it.
Work will continue offline on this and share any findings with the WG.

No feedback has been received from Aleph Zero on this matter.

https://github.com/camaraproject/BlockchainPublicAddress/issues/79

WG

NEW

08/MAY/25: Scope issue for the API blockchain-public-address generated

https://github.com/camaraproject/BlockchainPublicAddress/issues/86

WG

NEW

08/MAY/25: Scope issue for the API blockchain-public-address-validation generated

fix typo and url link - https://github.com/camaraproject/BlockchainPublicAddress/pull/93

MASDXI

CLOSED

05/JUN/25: Editorial PR, fixing typos in WG administrative information. Merged on June 5, 2025 after the meeting

AoB

WG

• Georgios and Pedro: Continue to work offline on the on-chain/off-chain solution for public address handling and report back to the WG when a solution is identified.

• Pedro: Will work on elaborating proposal for next RC. Currently is targeted for 21st June.