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
As an attestation consumer,
I want to be able to check if an address has an attestation using the ERC-721 owner method,
So that I can consume attestations without having to write new code for my dapps
Description
Many promotions, quests, loyalty programs and gating mechanisms already use NFTs as a standard. If we implement at least part of the erc-721 interface, then all of those dapps will be able to read from Verax without having to write any extra custom logic on their end. From their perspective, they will not be reading "attestations" but will simply be checking if an address has an NFT (which is what they do already).
This would be implemented on the portal level, thereby turning that portal into a quasi-SBT.
To do this we would need to provide an example portal that implements at least the following two function:
/// @notice Count all NFTs assigned to an owner/// @dev NFTs assigned to the zero address are considered invalid, and this/// function throws for queries about the zero address./// @param _owner An address for whom to query the balance/// @return The number of NFTs owned by `_owner`, possibly zerofunction balanceOf(address_owner) externalviewreturns (uint256);
/// @notice Find the owner of an NFT/// @dev NFTs assigned to zero address are considered invalid, and queries/// about them do throw./// @param _tokenId The identifier for an NFT/// @return The address of the owner of the NFTfunction ownerOf(uint256_tokenId) externalviewreturns (address);
The ownerOf function would simply convert the uint256 _tokenId param to a bytes32 attestationId and retrieve the respective attestation.
The balanceOf function would return the number of attestations that a subject has. This would require that the address _owner be cast as bytes and used to look up mapping (bytes => uint256) numberOfAttestations; and this would obviously require maintaining this mapping in state.
Ideally these functions would however be implemented on the portal level, as then the portal can be regarded as a NFT by other dapps that don't yet know anything about attestations. They can query the portal directly, and the portal can return the attestation metadata as a tokenURI which it can refer to an indexer (passing the token id) or some off-chain attestation data.
The text was updated successfully, but these errors were encountered:
alainncls
changed the title
[US] As an attestation issuer, I would like to remain compatible with the ERC-721 standard, So that it is easy for existing platforms to consume my attestations
[US] As an attestation issuer, I would like to remain compatible with the ERC-721 standard
Aug 31, 2023
One question on this user story - as subject is used as owner, what should happen to those attestations whose subject is not address type. Because the type of subject field is bytes?
As an attestation consumer,
I want to be able to check if an address has an attestation using the ERC-721 owner method,
So that I can consume attestations without having to write new code for my dapps
Description
Many promotions, quests, loyalty programs and gating mechanisms already use NFTs as a standard. If we implement at least part of the erc-721 interface, then all of those dapps will be able to read from Verax without having to write any extra custom logic on their end. From their perspective, they will not be reading "attestations" but will simply be checking if an address has an NFT (which is what they do already).
This would be implemented on the portal level, thereby turning that portal into a quasi-SBT.
To do this we would need to provide an example portal that implements at least the following two function:
The
ownerOf
function would simply convert theuint256 _tokenId
param to abytes32 attestationId
and retrieve the respective attestation.The
balanceOf
function would return the number of attestations that a subject has. This would require that the address _owner be cast as bytes and used to look upmapping (bytes => uint256) numberOfAttestations;
and this would obviously require maintaining this mapping in state.Ideally these functions would however be implemented on the portal level, as then the portal can be regarded as a NFT by other dapps that don't yet know anything about attestations. They can query the portal directly, and the portal can return the attestation metadata as a tokenURI which it can refer to an indexer (passing the token id) or some off-chain attestation data.
See the erc-721 specification for more details.
The text was updated successfully, but these errors were encountered: