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

HIP-904 Support Token Airdrops #8275

Open
Tracked by #8081
edwin-greene opened this issue May 10, 2024 · 0 comments
Open
Tracked by #8081

HIP-904 Support Token Airdrops #8275

edwin-greene opened this issue May 10, 2024 · 0 comments
Labels
database Area: Database enhancement Type: New feature parser Area: File parsing

Comments

@edwin-greene
Copy link
Contributor

Problem

Add support for the following transactions and persist to the token_airdrop table:

  • TokenAirdrop
  • TokenCancelAirdrop
  • TokenClaimAirdrop

Solution

  • Add a TokenAirdrop domain object with the same fields as the schema below.
  • Add onTokenAirdrop method to EntityListener to handle inserts to the token_airdrop table.
  • Add TokenAirdropTransactionHandler which will add a new entry to the token_airdrop table with the default state of PENDING.
  • Add TokenCancelAirdropTransactionHandler which will set the state of the airdrop to CANCELLED
  • Add TokenClaimAirdropTransactionHandler which will set the state of the airdrop to CLAIMED

If a TokenAirdrop transaction occurs for a fungible token that already exists in the token_airdrop table then the existing entry should have the timestamp range closed, and it should be moved into the token_airdrop_history table. If the entry was in the PENDING state, then the new entry should be updated with amount set to the sum of the existing amount and the new amount. If the existing entry is in any other state, then the amount should be set to the amount of the new entry.
If a TokenAirdrop transaction occurs for a nft that already exists in the token_airdrop table i.e matching sender, receiver, token_id and serial_number, then the existing entry should have the timestamp range closed, and it should be moved into the token_airdrop_history table.

Token airdrop schema:

create type airdrop_state as enum ('PENDING', 'CANCELLED', 'CLAIMED');

create table if not exists token_airdrop
(
    amount              bigint,
    receiver_account_id bigint         not null,
    sender_account_id   bigint         not null,
    serial_number       bigint,
    state               airdrop_state  not null default 'PENDING',
    timestamp_range     int8range      not null,
    token_id            bigint         not null
);

create unique index if not exists token_airdrop__sender_id on token_airdrop (sender_account_id, receiver_account_id, token_id, serial_number);
create index if not exists token_airdrop__receiver_id on token_airdrop (receiver_account_id, sender_account_id, token_id, serial_number);

create table if not exists token_airdrop_history
(
  like token_airdrop including defaults
);

create index if not exists token_airdrop_history__token_serial_lower_timestamp
  on token_airdrop_history using gist (timestamp_range);

Alternatives

No response

@edwin-greene edwin-greene added enhancement Type: New feature parser Area: File parsing database Area: Database labels May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
database Area: Database enhancement Type: New feature parser Area: File parsing
Projects
None yet
Development

No branches or pull requests

1 participant