HackaTRON S3 community topics - $5K in prizes!

This ia amazing I’ll try to contribute in hackathon post

1 Like

Thanks for all the great recommendations so far. We will be sure to take note and discuss it with the TRON DAO team on how we can improve subsequent hackathons!

A short answer for vote buying/vote exchange, it is not allowed and the hackathon admin team will state it again clearly during the hackathon voting period. Ultimately, we want to have a project that is useful and liked by the community, not a project that can make most friends and have them vote for them. There will be a series of vote authenticity checks during and after the poll to ensure that votes are from legit users.

Now, since “projects with repeated entries” were brought up here, let’s discuss this topic in-depth.

Q. For S4, how should we deal with projects that have entered a past TRON hackathon? How do we define an extension of an existing project (e.g. If a project participated in an existing NFT track in S3 and they utilized the NFT and created a game in S4, does it count as a new or existing project)? It’s hard to draw boundaries so let’s see what you all can come up with!

Q. For those who are not following our HackaTRON S3 closely, we actually do have a mini-hackathon that was done on-site (offline) in the U.S. Let’s say for S4, teams that met certain qualifications will have to present to judges on-site, will this make the hackathon more exciting and legit? Please share your thoughts on having on-site hackathon events as part of our ongoing online hackathon.


I believe that if a team initially created an NFT, they can then create new use case compatible with that old NFT, for example: Game, in order to avoid dumping to zero.
This project must be viewed as an old project with a new use case to support the old NFT project. This shouldn’t be considered a brand-new endeavour.

If a project creates an nft collection and, few months later, enters the hackathon again with a game that isn’t related to those nft’s, the game will be judged as a brand new product. Why would it be different if the team decides that the existing nft’s could be used in-game?

For the nft track, the product being judged is the nft collection as what it is during the voting period, not the fact that it’s potentially going to be used in a game in the future. We can only judge what has been delivered, and not some plans for the future. Otherwise projects can start to over promise and get rewarded for something that doesn’t exist yet and might never exist.

If in the next hackathon that same team presents a game using those nft’s, only the product developed during that hackathon should be considered. The game.

I understand that you consider that in this example the game is kind of an extension of the nft collection. But then you will judge the whole thing at once.

Actually I think the game is totally separated and the nft’s shouldn’t be taken in consideration while judging the game. Since it’s the game that has been developed for the second hackathon. It reduces the chances for that project to win if an other project is presenting a brand new game with a brand new nft collection at once.

I will take an other example. Let’s say I present a swap for a hackathon. Then for the next season I present a staking pool or a new design. Then first the hackathon organisation should ask themselves: is that a major improvement? If they decide that yes it is, then people shouldn’t evaluate the swap. They should evaluate the staking pool only or the design only. And they should ask themselves, is a design or a staking pool enough to win a hackathon that has been organised in order to bring talents to the ecosystem and reward products for their innovation, originality, complexity,…?

1 Like

This is a matter that is very important but also hard to define clearly. I believe that a “significant update” should be easy to determine. For me that definition means a major new feature of an existing project or a completely new dApp from the same team. In S3 there are some obvious carry-overs from S2, some are just cosmetic changes, other are updates of products that were not even completed after S2, which is even worse.

Following your example, if in S3 a team makes a new NFT ecosystem and in S4 creates a game using the NFT as a part of the game, for me it’s perfectly fine. But if a team proposes an app in S3 and a purely graphic rebranding in S4, I don’t think it qualifies as “significant update”.


For me a significant update is easy to define, it’s something that could be presented as a new product.

I will take @intercroneswap as an example. For the season one they have presented the swap if my memory is good. For the second season they have presented analytic tools that have been integrated to the swap. I think the analytic tools could have be presented by themselves as a product. Not just like a feature. So for me that application was valid.

I don’t know if I explain properly. What I mean is that the feature, to be significant, could be presented “out of context”, not like an improvement but as a brand new product.

Edit: I should have read your comment twice. What I’m saying is pretty similar to it ^^

1 Like

They sent the exact same to my friend too.

1 Like

Thats a wonderful question, i will tackle it from these angles, during judging of projects, are the projects milestones/roadmaps taken into consideration when judging? If all these are factors considered in the judgement then a project extension should not be considered as a new product deemed worthy of another hackathon submission.

Example; if project A submits a product for S1 hackathon say “swap feature” and includes in their milestone that they will add a staking pool later, which might even be under production. Then that staking pool feature if submitted for s2 should be disqualified, because if winners are to be paid based on milestone accomplishment, they would have had to complete this staking pool feature before they would have received their price for season 1.

But if milestones are not considered in the judgement process then the ability of the staking pool to function as expected should be considered as a product on it own without looking at the relationship it has with the swapping feature.

Presenting projects on-site will go along way to help us understand how far the team of various projects are willing to go to accomplish their timelines.

Up till now some projects have not given enough updates as possible, with over 200 projects submitted, if on-site presentation is a requirement after reaching a certain qualification, most projects will be disqualified and help clean the system.

People who also try to make some minor changes to existing products submitted for a previous hackathon will be caught in the process.

Also it will help various projects to bond well with other participants in the forum as they will all meet on-site to share their views and ideas from diverse background and cultures.

The on-site presentation videos can be posted on the forum for all to see how well products well articulated in the explanations. Those of us who cant join on-site can join through zoom or google meet to ask our questions after presentations are done. Thank you

1 Like