Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cardano-transfer primitive] returns more than transfers #325

Closed
SebastienGllmt opened this issue Mar 21, 2024 · 1 comment
Closed

[cardano-transfer primitive] returns more than transfers #325

SebastienGllmt opened this issue Mar 21, 2024 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@SebastienGllmt
Copy link
Contributor

SebastienGllmt commented Mar 21, 2024

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:

  1. 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)
  2. 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:

  1. For outputs, we need just RelationFilterType.Output
  2. For smart contract inputs, we need
    1. RelationFilterType.Input
    2. RelationFilterType.StakeRegistration
    3. RelationFilterType.StakeDeregistration
    4. RelationFilterType.StakeDelegation
    5. 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

@ecioppettini
Copy link
Contributor

The filter we want to use depends on the situation:

Do we want this to be a setting? Or would #332 be enough?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants