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

WG

ON-HOLD

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

19/JUN/25: Additional feedback provided within the issue. Georgios comments probably this issue has been opened not having the context of this WG. Pedro indicates has focused on identifiying topics for RC Pull Requets not checking it into detail so far. They will discuss this topic offline next week.

17/JUL/25: Neither Georgios nor Pedro have being able to dedicate time for this issue in the last weeks. Have agreed to discuss offline during 28th July week.

31/JUL/25: After offline discussion between Georgios and Pedro we are aligned internally within the WG. First of all this issue will not covered during this MetaRelease. We initially think that the use of CAIP-10 standard seems to be the more feasible solution for this issue (even not being fully user-friendly). Even it may be foreseen as a long-term solution, we agree on wait until having early implementations and feedback from them prior to move forward with a solution for this issue. Also check how solana and cardanoare represented under this CAIP-10 model.

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

WG

ONGOING

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

31/JUL/25: Work for Release Candidate Completed. Release Candidate tag generated r2.1

Next steps are to align API specifications and Tests with Public Release of Commonalities, and afterwards generate Public Release PR (end of August)

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

WG

ONGOING

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

31/JUL/25: Work for Release Candidate Completed. Release Candidate tag generated r2.1

Next steps are to align API specifications and Tests with Public Release Commonalities, and afterwards generate Public Release PR (end of August)

AoB

WG