[HACK BOUNTY] $HYPE leaderboard

HYPE leaderboard

I’ve implemented a board component that retrieves the $HYPE balance of a (so far) hard-coded list of accounts. It uses a wallet connection stored in a newly introduced application-wide state, which is applied by the $HYPE registration button during sign-in process.

Open questions

  • Who do we compile the account list? Some options we discussed so far:

    • Querying all token holders (seems to be an recurring unsolved issue in the NEAR community)
    • Query DAO members from Sputnik contract (probably no out-of-box support)
    • Hard-coded
  • How to make board accessible from UI?

    • $HYPE registration button is a drop-down menu when wallet connected and contains the following links:
      • Board → /token/board (this component)
      • Send → /token/send (to be implemented by Send $HYPE component)

Looking forward to your feedback!

3 Likes

This is awesome so far!

After we chatted, I found this example code to get recent transaction details.

In the spirit of decentralization, this seems like something well suited for a Graph Protocl subgraph, as I hear they’ll be working with NEAR soon!

In the meanwhile we could cache data server-side and query blocks ourselves… I dont know the best way to go about that, do you have any input @EV3RETH?

1 Like

As far as getting the data goes, we either need to cache/index transactions ourselves or wait for Graph to provide a similar service.

UI wise I was actually thinking the $HYPE button on the left would act as the portal to all things $HYPE related. Although we do need to figure out a system for sub/pages and navigation as we add more areas to the site. Looking forward to chatting with you about it all!

2 Likes

@mxjxn Thanks a lot for the hint. I managed to build a CLI tool called near-ft-query that can find and decode contract calls to hype.tkn.near for in interval of blocks:

➜  near-ft-query git:(main) ✗ ./bin/run test
Testing query...
Reading block AdLkmrttoBqYsbk386UdsDSqbFMKu3hcoAXp8DPSpu9D
Reading block 83vrZzXWPYc14a7ZzdywfW9HevNy1TWTT1hxKLu2rDZU
MATCHING TRANSACTIONS:  [
  {
    actions: [ [Object] ],
    hash: 'EkjKtijwBywPmtzKQNpqDnTK5Xb5utqZ4kGzRQMqQabz',
    nonce: 42193076000053,
    public_key: 'ed25519:9uAJ83bgcStumeWccZyaGm4Bwd1Cou3joLbmurDafw6x',
    receiver_id: 'hype.tkn.near',
    signature: 'ed25519:329hJn4KkChNASazBCvdzjRjMuhncsMYpd4TaoJVa4AsuD7x9KGAVjF4qap9rYNYo4GbFtSH2w2xJdEtooSrv7Wm',
    signer_id: 'mxjxn.near'
  }
]
TRANSACTION LINKS:  [
  {
    method: 'ft_transfer',
    arguments: { amount: '25000000000000000000', receiver_id: 'lilses.near' },
    link: 'https://explorer.near.org/transactions/EkjKtijwBywPmtzKQNpqDnTK5Xb5utqZ4kGzRQMqQabz'
  }
]

@EV3RETH I think it would be cool to develop that further and cache all $HYPE balances in a JSON file, that an update would only append to. We could then try to run this update once a day from somewhere (Github CI, if it allows such a long-running “blockchain task”) and store it on IPFS or Arweave?

I’ve continued working on this a bit and might have come up with an intermediate solution prior to GraphQL support.

The CLI block query tool near-ft-query can now be used to

  • a) Initialize a cache file that contains timestamps, the oldest block and all active accounts. These can be passed via the commandline: near-ft-query init erikli.near,mxjxn.near
  • b) Update an existing cache by querying all active accounts between the oldest block and the current one (currently hard-coded)

This gives us the opportunity to create a cache file with a (so far hand-compiled) list of active accounts from the time of HYPE creation until today. This file could be stored on Github where the leaderboard component reads it from. We could move on with that.

The next step could be to test the update mechanism and decide on an environment to run the CLI in. From here the cache file could be updated daily by taking only the blocks since last update into account.

And here’s a list of all active accounts (excluding councils) that have their receiver_id set in ft_transfer from block #43446577 to block 45884317:

  • chloe.near
  • defeatofclay.near
  • empress.near
  • holikao.near
  • joshua.near
  • jsnow.near
  • lilses.near
  • magusz.near
  • marafonec2021.near
  • q-hmd.near
  • starpause.near
  • tabear.near
  • trendheo.near
  • verbash.near

Ps: based on a manual explorer query :wink:

Also, I’ve made it available in the right JSON format here

Thank you for all the work thus far. I will say anything that needs to be updated manually is kinda outa the question.

We are going to be building a DB of active users and artists shortly, I think the best short term yet scalable solution is to wait on that and have "$HYPE amount just be a field/column in the profile table.
Every-time a user logs in we would update their total HYPE amount, and we could also make a master function that iterates through active accounts and manually updates their info in the DB

If your CLI command can check the entire history in an efficient way, then we could just have it be a button that people click to build the leader board in real time. That would be sufficient for now till the db is up

Spent some time thinking about that earlier today. The most important part is getting all accounts that received $HYPE through the contract, right? As long as I’m not missing something here, we’d either need an indexer that updates that list every time ‘ft_transfer’ was called or scrape recent blocks and do the update ourselves (pseudo-indexer). Both need some thinking where that account list is stored and where the (pseudo)-indexer should run. The pseudo-indexer needs more thinking on how and when to efficiently retrieve new blocks.

So if we have that list somewhere stored and updated, the actual amount an account has can be retrieved from the contract via direct call in realtime.

@EV3RETH Could you give some more information on how you’d imagine the mechanism to work considering your idea on the login update?

My thinking is we just have a API call that updates a users stored HYPE amount on our soon to be db every time a user connects their wallet/makes any meaningful tx through our site. We wouldn’t really be interacting with blocks at all. Just logging info when we observe it via user activity.
Obviously this is a very limited way of doing things. But I don’t think we have the capabilities to run our own true indexer.

Contacting you via Telegram to see how we can call this bounty complete as the ideal situation means waiting a bit.

Omg, I couldn’t stop working on it. But I came up with a system that could for us until the internal database is ready (because I also liked the idea of updating it on login, @EV3RETH).

I moved the CLI tool into the HypeDAO repository and created a Github Action. That action runs the CLI update command in order to automatically update a manually initialized JSON cache file every hour. This cache file lives on a separate branch in the monorepo.

List of components:

So, my plan to get the leaderboard going would be:

  1. Finish leaderboard UI component and move that out of WIP and thus finish the bounty
  • use newly introduced JSON cache file from Github and retrieve account balances based on that file
  • Make leaderboard available from HYPE registration button (through drop-down)
  1. Stabilize and finish up account cache mechanism (more testing)

What does everyone think about this?

2 Likes

That sounds awesome! Great plan

Hi All! How do I apply for a MetaBuidl “NFTs & DAOs” Challenge?

1 Like

I will create a new thread about the hackathon right now, please submit your idea that you’d like to start working on there!! Thanks for asking!!

1 Like

Forgot to tag you in my reply but check out the new post I made! Just give it a read and submit a reply to get started!

1 Like

Hey all, I’ve updated the cache mechanism. It should update $HYPE receivers in this JSON file every 30 min.

Would be cool to get some more testing (as I might just spotted unintended behaviour in transaction match function).

Please also check the PRs and action runs on Github, linked here.

Thanks :slight_smile:

1 Like

This is amazing, you’re an absolute legend! Looking forward to taking a closer look as soon as I can! Got a big bounty coming your way for sure for all the great work you’ve done!

PRs have been checked, just a couple requests and then we are all good!

So, I hope this is the final update :slight_smile: I’ve pushed more changes to both PRs:

Cache

Leaderboard

There’s a preview deployed here: https://hype-dao-bxznyltsf-hypedao.vercel.app/

Please let me know, if there’s anything that needs to be changed :slight_smile: