Implement a reflection token

Hi everyone,

I am new to the forum so apologies if I didn’t pose this question in the right category.

I would like to implement a reflection token in Solana. This is, for example, to use a percentage of each transaction (tax) to reward token holders.

I was wondering if anyone had done something similar and could provide some recommendations/guidance.

I guess this requires a custom program to be deployed to the chain that implements the taxation logic??

Thanks in advance and regards

Hi @srojasbg and welcome to the forum! :wave:

Implementing a token like that would require creating a custom token program. Unfortunately this has the side-effect of making it incompatible with existing Solana wallets. That means that users would have to use your own app or web-app in order to send, receive, and check the balance of their token.

For learning to develop on Solana in general, I suggest taking a look at Figment for some good beginner introduction to getting started with Solana:

Other than that, feel free to ask questions here on the forum!

When you’re ready to get started developing your token program, I’d say it’d be good to read through the docs here if you haven’t already, and then maybe start reading the docs and source for the SPL Token Program to understand how it works.

Then you could write your own token program similar in concept to the SPL Token program, but with your own modifications for handling the fees.

There’s also two options for how to write the program, you could use out-of-box Solana tools raw, like the SPL Token program does, or you could use the Anchor framework.

Anchor is coming out as a new but great way to write contracts with extra nice features such as reproducible builds and auto-generated clients, but it’s very new and isn’t super well documented yet.

I say that it’s good to know how to write Solana programs with Anchor, but Anchor is still a great option that might make your contract code simpler and more beginner friendly, assuming that you don’t run into issues with the lack of Anchor documentation.

And again, if you have any questions, just ask here on the forum, or maybe on Discord. A lot more devs hang out on Discord, and I’m the only here answering questions on the forum, so for questions I don’t know the answer to you might need to ask Discord.

Still, I like promoting the forum because I think it’s a nicer place for users to search and continue conversations. :slight_smile:

1 Like

Thank you very much for your quick response @zicklag.

I have followed the Figment learning path. I am at the moment learning anchor (have followed the small tutorial to store tweets in Solana).

I am finding it really interesting and intuitive to follow.

I have a potential requirement to implement a token with the customisations that I stated above (reflection) and I thought it could be a good POC.

A bit gutted to hear that implementing this sort of customisation would make the token incompatible with Solana wallets (e.g. Phantom).

Not sure whether this is a silly question but how is it done on other blockchains? For example, I hold a bit of Safemoon on Trustwallet. Safemoon is a reflection token on the Binance smart chain with all these reflection features.

Thanks again and regards

Yeah, I know. Unfortunately I don’t there’s any good alternatives for now. Hopefully they’ll be an option in the future.

And there’s still the possibility that there’s something I don’t know about, and you could ask on Discord. ( I’d appreciate if you post what you find here on the forum if you do find there’s a way to do it. )

The issue is just that, fundamentally, the SPL Token program allows anybody to transfer a token with “no strings attached” so to speak. If somebody wants to transfer a token, nothing can stop them or force them to pay a fee for doing it.

It’s not a silly question at all.

Honestly I’m not 100% familiar with how other chains do it. I know Ethereum has a very different data model than Solana, and it’s a very different technique for implementing tokens.

I think in Ethereum it’s kind of reversed compared to Solana. In Ethereum each token is a different smart contract I think, and there is the ERC-20 standard which defines the functions that each token contract needs to implement. Those functions could be implemented however that token contract wanted to implement them, including adding taxes, etc.

In Solana, though, we have one SPL token contract. And that one contract allows you to create multiple tokens. When you transfer a token or check the balance of the token, etc., all of those transactions go to the same smart contract, with the same logic.

I’d have to think about it more, but it would probably be possible to do a similar design to Ethereum on Solana, where tokens are free to implement their own transfer, balance, etc. functions, but we’d have to put together a solid project and design and then convince wallet projects on Solana to support our new token standard.