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
Currently, the cardano-transfer primitive queries the user-provided credential in extensions.yml directly to the Carp history endpoint.
However, the Carp history endpoint looks for anywhere this credential may have appeared in any structure in Cardano (not just transfers).
As a reminder, there are 2 main use-cases where you might want to track an address:
Output for when you want to check when somebody sends money to an address (ex: buying an in-game asset by sending money to an address)
Input for when you want to check when somebody executes a specific smart contract (since Cardano smart contracts appear in the input)
The filter we want to use depends on the situation:
For outputs, we need just RelationFilterType.Output
For smart contract inputs, we need
RelationFilterType.Input
RelationFilterType.StakeRegistration
RelationFilterType.StakeDeregistration
RelationFilterType.StakeDelegation
RelationFilterType.Withdrawal
This should fix the problem. We should be explicit in the docs though that this means that this primitive will not match on transactions where just the staking key matches the credential and not the payment key. I think this is fine because checking if somebody sent to an address with a specific staking key seems like an anti-pattern and they should probably instead be using the cardano-stake-delegation primitive
The text was updated successfully, but these errors were encountered:
Currently, the
cardano-transfer
primitive queries the user-provided credential inextensions.yml
directly to the Carp history endpoint.However, the Carp history endpoint looks for anywhere this credential may have appeared in any structure in Cardano (not just transfers).
As a reminder, there are 2 main use-cases where you might want to track an address:
The filter we want to use depends on the situation:
RelationFilterType.Output
RelationFilterType.Input
RelationFilterType.StakeRegistration
RelationFilterType.StakeDeregistration
RelationFilterType.StakeDelegation
RelationFilterType.Withdrawal
This should fix the problem. We should be explicit in the docs though that this means that this primitive will not match on transactions where just the staking key matches the credential and not the payment key. I think this is fine because checking if somebody sent to an address with a specific staking key seems like an anti-pattern and they should probably instead be using the
cardano-stake-delegation
primitiveThe text was updated successfully, but these errors were encountered: