You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug Docs say that deriving from AbstractPortal is "highly encouraged", which is != "required". PortalRegistry actually requires the portal to implement AbstractPortal interface to register.
To Reproduce Steps to reproduce the behavior:
Create a contract that doesn't inherit from AbstractPortal and provides a trivial IERC165 implementation:
Try registering a contract that contract with PortalRegistry.
Get the PortalInvalid(); custom error revert.
Expected behavior Registration should work. AbstractPortal should not actually be required. We don't need or want 90% of it. The IPortal should express the interfaces we actually have to implement. There should be no assumption that all portals are derived from AbstractPortal, but requiring an interface implemetnation is fine.
If we are forced to use AbstractPortal we will stub all the functions that we don't want with reverts - and nobody wants that.
Also, we'd like to have a library (instead of an abstract contract) that would provide the functionality we like, without forcing a specific interface.
For now, we'll lie about implementing AbstractPortal in our IERC165's supportsInterface implementation.
Screenshots Nope.
Additional context We are building a portal that would be easy to use - without the need for passing any attestation payloads as input (we have the msg.sender already and that's all we need to generate everything on the fly).
if (!ERC165CheckerUpgradeable.supportsInterface(id, type(IPortal).interfaceId)) revertPortalInvalid();
The text was updated successfully, but these errors were encountered:
MOZGIII
changed the title
[BUG] AbstractPortal implementation is *required* for portals, while docs specify it *highly encouraged*
[BUG] AbstractPortal implementation is *required* for portals, while docs specify it as merely *highly encouraged*
Jan 23, 2025
Describe the bug Docs say that deriving from
AbstractPortal
is "highly encouraged", which is != "required".PortalRegistry
actually requires the portal to implementAbstractPortal
interface to register.To Reproduce Steps to reproduce the behavior:
AbstractPortal
and provides a trivialIERC165
implementation:PortalRegistry
.PortalInvalid();
custom error revert.Expected behavior Registration should work.
AbstractPortal
should not actually be required. We don't need or want 90% of it. TheIPortal
should express the interfaces we actually have to implement. There should be no assumption that all portals are derived fromAbstractPortal
, but requiring an interface implemetnation is fine.If we are forced to use
AbstractPortal
we will stub all the functions that we don't want withrevert
s - and nobody wants that.Also, we'd like to have a library (instead of an abstract contract) that would provide the functionality we like, without forcing a specific interface.
For now, we'll lie about implementing
AbstractPortal
in ourIERC165
'ssupportsInterface
implementation.Screenshots Nope.
Additional context We are building a portal that would be easy to use - without the need for passing any attestation payloads as input (we have the
msg.sender
already and that's all we need to generate everything on the fly).The code in question:
linea-attestation-registry/contracts/src/PortalRegistry.sol
Lines 164 to 165 in 397541e
The text was updated successfully, but these errors were encountered: