Developing a Faucet for World Coin: Front End Work

By Daniel Goldman | The B.C.U. Times | 1 Aug 2019

This is the second half of my article on developing my faucet "game" and the third article on my WorldCoin project. It's been an interesting experience, and I admit that I'm kind of rushing things, but I think it's turning out pretty well. Here are my thoughts for developing the initial version of the front end, and getting everything running.

Initial Thoughts

So I was right that developing the front end was more difficult than developing the back end. At least with the back end contract, I can pretty much use the same standards that are employed in Ethereum contract development. Documentation for Tron is sorely lacking and there's a lot that's simply not clear. Website integration, for one thing, is fairly confusing. Tronweb documentation, in particular, did little to help me figure out how to access a Tron contract from javascript. That being said, I've managed to work some things out. I also manged to get Aptana working, after I realized that it needed the 32-bit version of Java rather than the 64-bit version!

Web3 Development

It's been so long since I've done any real website development, if one can call what I've done in the past "real" website development, that I had to relearn a lot. Luckily bootstrap and jquery are easy to use and make development a lot easier. I already knew I wanted a layout that featured whatever kind of ad, or other information I wanted people to really see, in the center, with status updates to one side and control options to the other side. This layout keeps people looking back and forth between the two sides of the screen, making it difficult for them to ignore the ad. I also knew that I didn't want the ad to be obnoxious. I wanted them to be kind of info cards, initially featuring information about the project, and eventually adding some sponsored content into the mix, and maybe a few actual ads mixed into the content. I hate faucets that are just an excuse to throw a ton of ads up all over the place though.

Handling Previews

In order to use Tronweb, you need a private key. TronLink injects a version of Tronweb directly into the DOM, so there's no need for an actual key when someone is signed in, but what about for accessing general information about the contract, that you want to have shown, even when someone isn't logged in? Adding the key in the source code makes it visible, which means you can't use your own private key that has any real value. So instead, it seems like the easiest way to handle accessing the contract when a user isn't logged into TronLink is to use Tronweb with a burner private key. So that's what I did. I created a new account that ONLY is used for the purpose of letting Tronweb access public info about the contract, and which will never be used to keep money in, and so it doesn't matter if the key is known! With that issue out of the way, I could set a timer to update the information once a second. 

Side note: it would be a fun little social experiment to have a private key that's publicly known, that anyone can use, knowing that anyone could pull the funds out at any time: a kind of "community fund." Of course, this idea could be implemented as a contract to allow a few limitations in how much can be pulled, etc.

Call vs Send

The first thing I needed to figure out was when to use call and when to use send. Call is used to call a method that is pure or view. Send is used when you want to change the state of the blockcahin, send TRX or a TRC-10 token, etc.

The really annoying thing about "send" in the documentation is that it doesn't mention anything about whether a things like feeLimit is needed or if there's a default value. It also doesn't mention a damn thing about the format for sending tokens, only TRX. I had to look at other projects to figure that one out. It seems that instead of "callValue", which is already odd since it's in the "send" function, you use "tokenValue" and "tokenId" instead. This value is not in whole units, but rather the smallest denomination. For TRX that's sun, and so if you want to send a certain number of TRX, you multiply the amount of TRX by 1,000,000. WRLD is also six figure precision, so it's the same multiplier when sending TRX and WRLD.

Viewing Public Variables

It would also be nice to know if there was a way to view public variables, without having to create a getter function. The answer is, when a Solidity contract is created, public getter functions are automatically created for public variables! Setters are not automatically created, which is smart, because that would make it very easy to accidentally write exploitable code. Still, in a few cases, I had created my own public getter functions, so I left them there to make it easier for me to remember what they are. 

Getting Things Running

I'm on a laptop and I didn't want to set up a full Tron node, and run my own testnet. I also didn't want to go through the headache of going to the Tron testnet, getting TRX for the testnet, creating a testnet token, and so on. What that means is that I did something that you should never do. I deployed the contract without testing it. I did however create a few helper functions that should make things alright should the contract fail in some odd way. First, if the faucet is inactive (no drips) for at least seven days, I can pull the WRLD from the contract. I can also withdraw any TRC-10 token, other than WRLD, or TRX, so long as I'm using the address from which I deployed the contract. That means if someone accidentally sends TRX or TRC-10 tokens directly to the contract, I should be able to pull them and return them, if I did everything right. Finally, I'm starting the contract with only 1,000,000 WRLD, which is only 1/10th of a percent of the entire number of tokens created. If all goes well, I'll send over another 250,000,000 and let the contract run its course. 

Obviously I found a ton of errors after I started the contract up and had enough of the interface together to start testing it. I was able to test some operations even before adding any tokens to the contract, because some of them were simply view functions that did not change anything on the chain. The main issue was that I wasn't paying attention to unsigned arithmetic and taking into account that the first drop has to occur before certain variables are set. A few things about contract deployment. The documentation isn't very clear about setting max fee. I just left it as is. Also, even a small contract like mine costs about 1 million energy, so make sure you have energy available. I stupidly forgot and it cost me some TRX. 

Alpha Running

I think I went through about five contracts before I worked out all the major kinks. And while I'd still consider this version an alpha, the faucet is live. Because drip size increases as the time since last drip increases, the drops might be pretty big for a while. I sent over 100,000 WRLD just to start, and if things take off, I'll definitely send over a lot more to make sure the "game" continues. I just don't want to lock away too many WRLD before the contract has been tested for a while. I did also set the default referral address to my personal account, but anyone can refer anyone they want (except themselves obviously) by changing the ref value in the URL to their own TRX address.

The two absolute biggest headaches was definitely the issues created by using unsigned arithmetic and that I had to remember when to multiply and when to divide by 1 million to get the right value for the tokens! Seriously though. I thought it would take me a few weeks before I even had code that compiled. But it's really operational (sort of). Like I said, it's alpha. Use if you want, but there's no guarantee that the tokens will actually be distributed. 

That being said, I really hope that this initial project will help gather interest in this project, and also perhaps in some other projects, once I add the central ad cards. And remember, if you have any questions, visit the Telegram chat

Originally published on Uptrennd

How do you rate this article?



Daniel Goldman
Daniel Goldman

I’m a polymath and a rōnin scholar. That is to say that I enjoy studying many different topics. Find more at

The B.C.U. Times
The B.C.U. Times

The B.C.U. Times - blog about promoting the blockchain and cryptoasset user experience and ecosystem.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.