Yes, the pairing makes perfect sense, security verification and visual identification would provide secured security and better UX
right now, my current focus is delivering phase 1 to ensure the ownable pattern working code, tests and documentation is delivered. My aim is to prove this foundation works well and itβs adopted before expanding the scope.
I see the synergy here, while the security registry/security template proves the contract is secured, the identicon will recognize contracts visually. This could be explored as a future phase after the core security templates are established and proven valuable to the community.
So, what I think is, these proposals complement each other but should remain separate for now since each one solves a distinct problem. They can work together without being merged into one proposal. Looking forward to discussing this at the Feb 3rd WG.