Stories by Jeff Scott on Medium

Lamden ARKO is now LIVE!

Jeff Scott — Mon, 30 Jan 2023 21:31:45 GMT

After a long development cycle, Arko FINALLY lives!

Before I get to anything I just want to say that I am honored to work with some of the best and brightest people and I just want to call them out.

Stuart, Mykyta, Glen, and Allen have contributed a lot of time to get this deployment out the door and I want to thank them for being the best and smartest people I have worked with.

I also want to call attention to Paul Donald, Endogen (if that is your real name), Benji, and Crosschainer for keeping me honest about bugs and testing things as we went. You can never catch all the bugs, but you guys sure found a lot.

A final thank you to those that ran Testnet nodes and dealt with our development process in real-time. Thanks for sticking with us!

I’m sure I have forgotten many people, but I think you all know who you are.

Let’s get to the important stuff!

If everything goes according to plan the Lamden Vault Wallet should make the Arko Mainnet network option available at 5 pm EST (make sure you refresh the Vault after that time). Also, make sure you are on version v2.4.0. You can download the latest here.

“Arko Mainnet” is now the network you should use. A future update will remove the “Lamden Mainnet” and “Lamden Testnet” network options entirely to avoid confusion.

All $TAU balances and smart contracts values were transferred over to the new network.

Contact your favorite Dapp operator to see if you should start using their app.

Lamden Link will be down till at least tomorrow with Pixel Whale returning later this week.

Node Dashboard

The wallet now has a node dashboard section.

This is an image from Arko Testnet

This will be where Node Owners can view their rewards gained as well as raise and vote on network policies and motions.

Block Explorer

The great and powerful Coindab will have the Arko Mainnet Explorer up today after 5pm EST.

We will tweet out when it is live.

How do I become a Node?

A popular question! We will begin onboarding community nodes the week of Feb 13th. This will let us monitor the network for a couple of weeks as well as release some guidance on how to properly set up a node and what should be expected.

We will start by onboarding nodes from our Testnet node runners. After that Lamden will no longer have control of the network and it will be in the community's (your) hands.

DAO Funds

The DAO will be funded this week with roughly 40 million TAU will be put in the hands of the Lamden Node Group to make the project stronger than it has ever been.

Node Details

For developers, these are the master nodes and block services that Lamden is now running.

Masternodes

Masternode documentation

Block Services:

Block Service Documentation

The best practice should be to use WebSockets for getting state updates. Refrain from polling for updates as it causes too much traffic (ie sending “latest_block” requests a few times a second.

If you MUST poll, use all URLs in a round, robin fashion so you are not hammering one node in particular. As more nodes and block services come online the load can be spread around even more.

Network Stability

Arko has undergone months of testing but nothing is 100%. From a security standpoint, the code underwent an audit, and it contains the latest and greatest contracting version which also underwent an audit.

Just like the last chain we DO expect some downtime. I know this is crazy for a project to admit but nothing is bulletproof. Please be patient with the node group if issues arise and we need to fix things. In the short term, Lamden controls all the nodes so we hope that means a quick resolution to issues. In the long term, as a decentralized group, the Node owners will need to communicate on fixes and get the network back up in a timely fashion if something happens.

Issues

Please report any issues in the Lamden Telegram Room

Why Lamden?

It’s fast, with tiny transaction fees, and a developer-focus. Built from the ground up to remove technical hurdles and empower developers. Choose to program in Python, or your preferred language, and significantly reduce the time to produce your dApps. Developers are further incentivized since 90% of each transaction fee is returned to the dApp creator. $TAU has a maximum supply of 248 million and is deflationary with 1% of each transaction fee burned. Lamden is paving its own path as the premier Python-based layer-1 blockchain platform. With access to a potential developer base of over 10 million, the sky is the limit. Welcome to Lamden!

Lamden ARKO is now LIVE! was originally published in Lamden on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lamden Link Activated

Jeff Scott — Wed, 14 Dec 2022 18:04:09 GMT

It’s been a long road to recovery since the exploit took down Lamden Link but I am very happy to report that the Lamden Link bridge is now back up!

Here are some things you should know.

New BSC TAU contract

The exploiter bridged a sizeable amount of TAU to BSC and that caused us to pause the BSC TAU token contract to prevent a sell-off on Pancake Swap.

We have deployed a new TAU token contact on BSC and airdropped everyone their balances back, except the exploiter.

The new token contract is now unpaused and you can begin to trade on PCS again.

New TAU contract address (add to your crypto wallet)
Trade on Pancake Swap

Limited Tokens

We removed all tokens from the bridge except for LUSD/BUSD and TAU. So right now that’s all you can bridge. For most people that is enough.

We will be activating ETH within the next week or so.

As far as LIQ, BDT and DC are concerned we do not have the liquidity to restore these on the bridge yet. However, we will make every effort in the new year to restore these tokens.

Liquidity

Lamden had to burn all of their WETH and LUSD liquidity on Rocketswap. This allowed Lamden to absorb the financial loss of the exploit and not pass it on to the community. For now, I encourage the community to provide liquidity to the LUSD/TAU pair as we aren’t able to replace it in the short-term.

The Bridge BSC contract will be 100% funded with an amount of BUSD equal to the total LUSD that exists on Lamden.

When it becomes available, the WETH bridge to Ethereum will be 90% funded with the hopes of getting it to 100% in the future.

The TAU/BNB pool on Pancake Swap will remain as liquid as it was before, there is no change there.

New Bridge Feature

The bridge is made up of two types of contracts. One that handles tokens created on Lamden (Lamden Native Bridge) and one that handles tokens created on Ethereum Based Blockchains, like BSC (ETH Native Bridge). Previously to this update, the Lamden Native Bridge was only able to handle one token, TAU. But the new contract can now handle multi-tokens and as such, we can add other Lamden Based tokens to the bridge!

More on this to come and how project owners can bridge their tokens to BSC later.

Housekeeping

In order to move funds out of the old BSC bridge contract I had to mint and burn LUSD on Lamden. I did it incorrectly the first time so, I had to do it twice. For transparency, here are those transactions.

ATTEMPT #1

MINT 38,887.65 LUSD on Lamden
Burn 38,887.65 LUSD on Lamden
Withdraw tokens from old BSC Lamden Link contract (FAILED INVALID NONCE)

ATTEMPT #2

RE-MINT MINT 38,887.65 LUSD on Lamden
RE-Burn 38,887.65 LUSD on Lamden
Withdraw tokens from old BSC Lamden Link contract

Send test 1000 BUSD to new contract

Send rest 37,887.65 BUSD to new contract

Lamden Link Activated was originally published in Lamden on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lamden Wallet v1.8.0 — Cleaning House

Jeff Scott — Thu, 21 Oct 2021 18:00:50 GMT

Lamden Wallet v1.8.0 — Cleaning House

This is a guide to be able to merge and cleanup your Lamden Wallet accounts. There is no requirement or a deadline to do this, it’s just information if you want it😎.

Time to tidy up our wallets 🧼 🧽

With the new Lamden Wallet v1.8.0 release we now have Dynamic DAPP Connections.

This is a departure from how the wallet worked previously.

Previous to v.1.8.0 each time the wallet connected to a DAPP it would create a NEW account for that DAPP in the wallet. This was done to silo the DAPP away from your Main Account and provide an extra level of security between a malicious app and your funds.

While this seemed like a good idea when the Lamden Ecosystem was quite small the reality was, as Lamden became more popular, the amount of accounts the user had to deal with became unwieldy. This included keeping TAU in each account to allow transactions and tracking which account held which tokens or NFTs.

A bigger issue that I personally did not see was the paradigm shift for users who were just familiar with how other wallets like Metamask usually handle these connections. Even though users got comfortable with our paradigm, onboarding those users to Lamden had more friction than it was worth.

Thank god that’s all in the past!

Or is it? 🕵️‍♀️

After v1.8.0 you will have a new menu item called Dapp Connections

This one

Clicking this will take you to a new screen that lists all the DAPP connections your wallet has made. Next to the DAPP is the the account that you currently have linked. Clicking “Change Account” will bring up a screen that lets you change to a different account.

But, if you navigate back to the Accounts screen for a moment you’ll notice that it looks just a cluttered as ever! That’s because all the accounts that the DAPPS create still exist in the wallet. It seems we have some house cleaning to do!

The ideal situation is to take all these accounts and combine them into 1 or 2 accounts that hold ALL of our assets. And then point all of our DAPPs at just our main account. So when you go from Lamden Link to Rocketswap the same assets are being accessed.

Step 1a: BACKUP! 💾

Before we do anything, including deleting accounts, we need to do a backup. This is so if future us realizes we missed moving any assets we can recover the account to the wallet and have access to those assets.

You can CREATE A KEYSTORE, BACKUP KEYS MANUALLY or both.

Whichever you decide make sure you store the information SECURELY.

Be nice to future you, use something like LastPass to keep complex passwords safe but accessible. You will thank you later.

Step 1b: BACKUP!! 🛑

Seriously. Do it. This article will not be held responsible for lost assets.

Step 2: Select a main account 💃

From your list of accounts select which will be your MAIN ACCOUNT. I suggest going into this account’s properties and renaming it to just that. This will help to avoid confusion as to which account we are moving our assets to.

Step 3: Move Tokens 🪙

You can easily click on any of the tokens listed in your wallet to see which accounts have balances. Use this great tutorial to transfer those tokens to your MAIN ACCOUNT
What about tokens that you didn’t know you had? YOU’RE RICH BITCH! lookup your wallet address on www.tauhq.com it should show you all your token balances. Add any tokens to the wallet following this fantastic tutorial and then move them to your MAIN ACCOUNT

Step 3: Rocketswap Staking and Liquidity 🚀

Any staking you’re doing on Rocketswap will be tied to the Rocketswap account.

You have a couple options here:

Move everything:

Un-stake from all Rocket Farms. This will get back your tokens as well as any LP you had staked.
Remove all liquidity from the Rocketswap Pools dashboard
Un-stake anything in your RSWP Rocket Fuel Tank
Using this great tutorial transfer all tokens and TAU to your MAIN ACCOUNT
Rename Rocketswap account to OLD ROCKETSWAP ACCOUNT

Keep Account for Staking

If you’re heavy into the staking and liquidity pools and you just want to deal with this later then you can leave this account as is. You’ll essentially be swapping back and forth in the Dapp Connections page between your MAIN ACCOUNT for trading and this account for staking. If you empty your farms daily they may not be a great option. But if you’re a set it and forget it farmer then it’s probably the easiest for you.
Rename the account to Rocketswap Staking and leave some amount of TAU in this account for making transactions later

Step 4: Pixel Whale 🐳

There are two considerations for merging our Pixel Whale NFTs with our MAIN ACCOUNT.

Owned NFTs:

Anything you own can be transferred to your MAIN ACCOUNT by visiting the NFTs page on Pixel Whale and using the Gift button. Be sure the MAIN ACCOUNT address you paste in has no leading or trailing spaces!

Get yourself something nice

Created NFTs

If you have not created any NFTs from this account then move on
Creators are meant to never change. The creation of an NFT will always be tied to the account that created it. This was a design decision which I regret now but it is what it is.
This means that we need to keep this account around because anytime one of your Creations is sold then you will get royalties collecting in this account and you will want to have access to those
Rename this account to Pixel Whale Creator

Step 4a: Contract Developers 🤓

If you have ever submitted a contract you will get a cut of every transaction fee that goes through that contract. If you have not, then you can move ahead.

You can view the developer of any contract by replacing the contract name in THIS URL with your own.

So if you have an account that you want to get rid of now. You can change the developer of your smart contract to your MAIN ACCOUNT by creating this transaction. If you are a developer this should be familiar to you.

Make sure the account selected in the top box is the current developer account.

Developers should hopefully understand this

Step 4b: Contract Operators 🏗️

If you have never developed a Lamden Smart contract then you can skip this.

If you use the operator (or owner) paradigms in your smart contracts then hopefully you have built a mechanism to change who that is.

Implementation of something like this is in the hands of the developer. I just wanted to have this item here to remind you to check if any of your accounts are currently set as the operator or owner of any current contract before you toast them.

Step 5: Other considerations 💭

There are a lot of DAPPS on Lamden. New and OLD and depending on your time using Lamden you could have accounts and items all over the place.

Visit the communities that you value the most and ask around if there is anything more you should do before deleting an account.

Some communities to consider:

Nebula (NEB)
Underground Warriors (WP)
LambDoge (LDOGE)
CRUSADERS of LIGHT (search Telegram)

Hopefully these and other communities publish their own migration steps to help people clean up old accounts

Step 6: Send TAU and Remove accounts 🗑️

If you have backed up your accounts, and we all know you have, then you can go ahead and delete accounts that no longer are tied to any assets or you don’t ever plan to need again.

Before we do let’s get as much TAU out of the account as possible (dust may remain). Use this brilliant tutorial to send TAU from all accounts you are going to delete to your MAIN ACCOUNT.

How to squeeze out as much TAU as possible?

Stamp Limit: 25 Stamps
Amount to send: Total TAU in account subtract 0.4 TAU

SO if I have 10.8 TAU in my account I’m going to set the stamp limit to 25 and then set my amount for the transaction to 10.4 (10.8–0.4).

If you need them in the future you can restore them from the keystore backup or add specific accounts back via private key.

Wallet may be less shiny than picture depicts

All done! Hopefully we have cleaned up your wallet even a little and it’s now a happier place to be!

Learn more about Lamden

Check out our website
Chat with us on Telegram or Discord
Follow us on Twitter

Lamden Wallet v1.8.0 — Cleaning House was originally published in Lamden on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lamden Link: Lamden’s Bridge to the Blockverse

Jeff Scott — Fri, 02 Jul 2021 13:57:29 GMT

Introducing Lamden Link!

Blockchain has dominated the technology space for the last decade just like the internet has done for the past two decades. Blockchain provides a secure and fast means of carrying out transactions with the use of impossible to hack ledger technology. Blockchain technology continues to grow both in popularity and usage as many industries are starting to accept it as a reality.

The benefits of blockchain technology cannot be overemphasized with quite a number of industries already implementing blockchain solutions ranging from finance, health, service etc. However, business implementation of blockchain technology is still quite difficult and this leaves a gap between businesses and decentralized technologies. There are many challenges that enterprises face when trying to adopt public and private blockchain technologies.

This is where the Lamden blockchain comes in handy. Lamden is a blockchain built with python. It’s open source, cheap and fast to use. It supports python contracts that are easy to write and test. That means Developers who already know python don’t have to learn any new programming languages or workflows. With Lamden, everything is open-source. You can re-use functionality that others have built into their smart contracts. This means you can build smart contracts faster with Lamden.

Lamden has been around since 2018, and having launched their Mainnet in September 2020, the team has been able to spur the community run DEX Rocketswap, an NFT minting and marketing place pixelwhale.io and a NFT based game Underground Warriors which is still under active development.

Our blockchain basically focuses on the needs of our:

Users/Investors
Developers

Lamden Link, which enables interoperability, is a two-way bridge built to convert ERC20 tokens from the Ethereum blockchain to the Lamden blockchain and back again.

You might want to ask what the Lamden Link is all about. What is an Ethereum bridge, or more precisely what is a Lamden-Ethereum Bridge? As the name implies it allows movement of ERC20 tokens between two chains. So tokens can flow across to be used within the Lamden ecosystem. This includes Wrapped Ethereum Token (WETH) which is the first to launch and effectively bridges Ethereum’s value to the Lamden ecosystem.

Lamden Link is very important because currently Ethereum has a lot of dapps being built on it which means a larger market capitalization for Ethereum tokens and this bridge allows these dapps and tokens to be able to easily migrate to the Lamden chain to enjoy lower gas fees, fast transactions and listing on the blazingly fast Rocketswap DEX.

The Future Of Lamden Link

Lamden Link is launching with Wrapped Ethereum Token (WETH) but will add more ERC20 tokens including stable-coins in the near future.

More chains will be added to the bridge as time goes by with the devs already working on that possibility.

Visit here https://www.lamdenlink.com

Lamden Link: Lamden’s Bridge to the Blockverse was originally published in Lamden on Medium, where people are continuing the conversation by highlighting and responding to this story.

Life Happens

Jeff Scott — Thu, 04 Mar 2021 19:15:26 GMT

The Rocketswap team has some good news and bad news.

Good News:

Benji’s and his wife welcomed their second child today!

If you’re in the Rocketswap Telegram room I hope you can wish him congratulations!

Bad News:

Benji is one of Rocketswaps lead developers and general project manager. We were hoping to get Rocketswap launched before the baby came, but, as they say, “Life happens”. So we’re going to postpone the launch of Rocketswap by one week so that Benji can take care of his family.

The rest of the team will continue development and Benji will catch back up with us next week to polish off the product.

Updated Timelines

All dates and events have been pushed one week. The new dates are as follows:

Rocketswap Launch: March 15th, 2021, 18:00 UTC
MAKE IT RAIN Event: March 11th, 2021, 22:00 UTC
* Dates have been changed in all previous blog posts

With ❤ — The Rocketswap Team 🚀🚀

Follow us on Twitter
Talk to us on Telegram
Live on Testnet

Life Happens was originally published in Rocketswap 🚀 on Medium, where people are continuing the conversation by highlighting and responding to this story.

4: Uploading your Smart Contract to the Blockchain

Jeff Scott — Sat, 14 Nov 2020 15:34:18 GMT

Wow, you made to Part 4!

Go Here to take a look at the previous tutorial parts.

To begin this tutorial you should have a project that mirrors this git repo.

Part 4 — Setup

At this point we have a smart contract and some interactions, but none of it is on the blockchain. A lot of the Dev Server and API work was to give you a ground level introduction to working with a blockchain and I hope you now have that understanding.

This next set of tutorials will have us uploading our smart contract to Lamden’s TestNet and applying what we have learned about interacting with the smart contract to change our frontend to work with the Lamden TestNet.

Lamden Wallet

Install

The first thing we need is Lamden’s Wallet. The wallet is a Chrome Extension that can be installed from the Chrome Web Store.

The wallet will allow us to do the following:

Make and safely store Lamden keypairs (wallets)
Upload our Smart Contract to the blockchain
Log users into our frontend by talking to the wallet
Have our frontend initiate transactions on behalf of the user

Once you have downloaded the wallet, open it and complete the first-time user setup.

When you get to the main screen you will need some test TAU (called dTAU). Head over to the Lamden Faucet to get some by copying your account address (vk)from the the Lamden Wallet and pasting it in the site.

dTau is free and has no value.

A quick note on keys. In cryptocurrency you have two keys referred to as a keypair. One of these keys you can share and one you keep secret. In this tutorial we will refer to the one you share as a vk or “verifying key” but you might have also heard it called a public key or account address. The wallet itself calls it an account address. Why are we calling it a vk and not an account address? Well we are developers now, and we need to use proper terminology!

The other key, the sk, is your “secret key” and is used to sign translations. Using cryptography the blockchain can read the digital signature of your transaction and match the vk to it. The Lamden Wallet takes care of safely storing your sk and automatically signing transactions. You should never need to manipulate your sk manually, and you can back it up using the Backup process on the left menu bar. (Which you should do now)

To copy your vk to the clipboard, click on your account in the list from the main Accoutns menu. Then click the Copy Address button.

**Make note of this vk as we will need to reference it later in the tutorial. This key is public information and is safe to share.

my_token.py

The first thing we need to do is make our seed method more dynamic. We hardcoded the value “me” to get 50 tokens but, we may not know the vk (public key) we will be using or the number of tokens we want as as supply, till later.

Open my_token.py and let’s give our seed method a “vk” argument and define it as string (str). We then will pass the vk argument down to the assignment statement where we assign 50 tokens. Now whatever vk we pass into this method will get minted the tokens.

Then we will give seed a second argument called amount, defined as an integer (int), which will be the token amount to mint at the time the contract is submitted. Replace the value 50 with our new variable amount.

#my_token.py

#Smart Contract State
S = Hash(default_value=0)

#This runs when our contract is created on the blockchain, and never again.
@construct
def seed(vk: str, amount: int):
    S[vk] = amount

#This method will be exported so our users can call it
@export
def transfer(amount: int, receiver: str):

We can now set these values when the smart contract is submitted. Then a vk of our choosing will get the initial supply of whatever amount we decide.

Save my_token.py our changes are complete

tests/test_contract.py

Let’s update our tests to pass vk = “me” and amount = 50 when we submit our contract to contracting. See changes in bold.

#tests/test_contract.py
import unittest

from contracting.client import ContractingClient
client = ContractingClient()

with open('../my_token.py') as f:
    code = f.read()
    client.submit(code, name='my_token', constructor_args={'vk': 'me', 'amount': 50})

client.submit() calls our smart contract’s seed method when it submits the contract. It knows to do this because of the CONSTRUCT decorator we used above the seed function. The constructor_args property tells submit to pass along this object as arguments to the seed method.

When client.submit() runs our seed method it will now run it like this:

seed(vk=”me”, amount=50)

When the above method runs me will get assigned 50 tokens to start.

Run the test file.

cd tests
python3 test_contract.py

All 3 tests should pass

Ran 3 tests in 0.016s

OK

server/contracting_server.py

Let’s make the same change in server/contracting_server.py.

See changes in bold.

# server/contracting_server.py

from sanic import Sanic, response
from sanic_cors import CORS, cross_origin
import ast
import json

from contracting.db.encoder import encode
from contracting.client import ContractingClient
client = ContractingClient()

with open('my_token.py') as f:
    code = f.read()
    client.submit(code, name='my_token', constructor_args={'vk': 'me', 'amount': 50})

app = Sanic("contracting server")
CORS(app)

Upload to the Blockchain

Uploading a contract to the Lamden Blockchain is done by calling the submission contract.

You can view the code for the submission contract on the blockchain here.

Let’s look at the submission contract code:

https://medium.com/media/976a455cf933a481548f4dd7dc5512e1/href

The submission contract is just 1 method called submit_contract and it take 4 arguments. Most of which should be familiar to you by now.

name: Contract name. Must be unique on the blockchain and must start with “con_”
code: Your contract code
constructor_args: Arguments for our seed method
owner: If an owner is specified then only that user (or contract) can transact with this contract. This is an advanced feature not needed for this tutorial series.

So, to upload our contract we need to make a Transaction with the same information we provided to server/contracting_server.py in Part 3b.

contractName: 'submission',
methodName: 'submit_contract',
kwargs: {
    name: "con_my_token",
    code: "contact code here",
    constructor_args: {
        "vk": "our public key",
        "amount": 1000000
    }
}

Luckily the Lamden Wallet will simplify this process for us.

Open up the wallet and click Smart Contracts on the left side menu. You should get taken to this screen.

Lamden Wallet — Smart Contract IDE

Click the blue + button next to the IDE tabs.

Click the Blank Contact button.
Paste the contents of my_token.py into the IDE.

my_token.py code in Lamden Wallet IDE

Clicking Check Contract should return the message Contract is Okay in the green box.

Before we go further make sure you have your wallet vk from earlier handy.

Click the Submit To Network button and you will get the following form to fill in.

From the Send Transaction From drop down select your wallet. This wallet will be the transaction sender (ctx.sender in our smart contract code).
Stamp Limit signifies how many stamps the system can use before the transaction aborts. On the current TestNet our submission transaction should cost about 200 stamps, which is about 10 dTau. There is no harm in leaving it higher, so we can set it at about 1000 to ensure the transaction doesn’t prematurely abort.
Contract Name is already filled in for us with submission
Function (another name for method) is already filled in and is the correct submit_contract method as we saw from the submission contract code above

These next 4 boxes are are the arguments we will supply to submit_contract

Name: We have been calling this contract my_token but there are two issues with using that name here. One is that all smart contracts need to be prefixed with con_ and con_my_token would work except for the second thing in which all smart contract names need to be unique. Multiple people will take this tutorial and that means everyone can’t use the same name. So here you get to be creative and replace my with whatever you want. I will use con_jeff_token, you use whatever you like.
Code: You can see the code string all packed in the box. Scroll down to marvel at your work.
Owner: Leave this blank as we want everyone to be able to transact with our contract.
Constructor Args: This is where we’re going to pass in the values to our seed method, just like we setup in or test_contracts.py and contracting_server.py. Copy and paste this JSON object into the box. Be sure to replace with the one you copied down earlier. Be sure to not have any spaces in the string, including leading or trailing spaces.

{"vk":"","amount":1000000}

This is my completed form. Yours should look similar.

** To continue further you need to have dTau in your wallet. If you don’t the submission transaction will fail with “bad seed size”.

Click the Confirm Transaction button

Say OK to this prompt and then you should get a successful result like below.

Click Close.

We can validate our contract is on the blockchain by finding it on the Masternode using the API. This is like how our Dev Server worked.

**Substitute your contract name for con_jeff_token in these Links.

Your contract’s code:

http://167.172.126.5:18080/contracts/con_jeff_token

Your contract’s exported methods and arguments:

http://167.172.126.5:18080/contracts/con_jeff_token/methods

Verify the initial minting of tokens to your vk:

http://167.172.126.5:18080/contracts/con_jeff_token/S?key=fc95219ed9e9bf31e36c2f70978a89a9e912b160c3daf28194f96d51298445b6

Quick functionality test

Looks like our smart contact is up on the network and we have our minted supply assigned to us. So, let’s do some quick testing.

Click the blue + button on the IDE

In the From Blockchain box type the name of your contract and then click the Open button.

You will now see your contract’s code that is stored on the blockchain. Notice your seed function has been renamed to ____ so it can never be run again.

All state variables have been appended with __ but you can ignore that when referencing them in code. For example, your State variable __S is will just be S when we use it.

Below the code box there is an easy way to query state. Put S in the Variable Name box, your vk in the keys box and hit RUN. Returned in the box below is the value of your vk in current state, which is the number of tokens we initially minted.

If you take a look back at the Masternode API URL this is the equivalent of doing:

http://167.172.126.5:18080/contracts/con_jeff_token/S?key=fc95219ed9e9bf31e36c2f70978a89a9e912b160c3daf28194f96d51298445b6

Below that we have a Contract Methods section and you can see our transfer method. This provides a simple way to run the methods in our contract.

There are two familiar argument boxes, amount and receiver. Previously we were testing just sending amount to “me” or “you”, and that will work here as well. The issue with that is that those are just string values and not keys so now one can controls the tokens after they are sent. That’s fine for testing but now how we want our app to work.

So, to test this properly we will need a second keypair, or “wallet” as the Lamden Wallet refers to them.

Let’s create one:

Click on the Holdings menu item on the left menu
Click the Add Wallet button in the bottom of the big purple rectangle.
Give this new wallet a nickname like Wallet 2

Then click the Save button

Now you have a new wallet, which in turn has its own keypair (vk & sk).

Click it the new wallet and then copy it’s vk to the clipboard by clicking the Receive Coin button and record it for use later.
Now go back to the IDE by clicking Smart Contracts on the left menu.
Make sure your contract is selected on the IDE tab and scroll back down the the bottom Contract Methods section.
Enter 100 into the amount box.
Paste the new vk we just created into the receiver box.
Click the RUN button beside the word transfer.
You will get another transfer form with the specifics already populated. We just need to select the sender for this transaction. In this case the sender should be the wallet that was minted all the coins. So, select that wallet from the Select Wallet to Send From drop down box.
Leave Stamp Limit the default.
click the Send Transaction button.

Assuming everything was done correctly you will get this confirmation box.

Click the Close button.
Head back to the Get Current State box and put S in the Variable Name box and our new vk in the key box.
click the RUN button to the right of the words Get Current State.

Our new wallet now has 100 JEFF TOKENS!

You can also put your original wallet in the keys box to validate that the 100 tokens were deducted from your supply.

DONE!

Things you should have a decent grasp of at this point having completed all 4 Parts to this tutorial:

Parts of a smart contract: state, methods, arguments, constructor method (seed method).
How to submit a contract to both the Python contracting client and the blockchain; using the IDE.
How to get the current state from a smart contract using both the Masternode API and the Wallet IDE.
The information needed to formulate a transaction: sender (ctx.caller), contractName, functionName, arguments (kwargs), stamp Limit.
How to send a transaction to a smart contract using the wallet IDE.

If you have got this far and are still struggling with these topics, then please leave a comment below.

I’m available to chat on twitter, telegram or linkedIn

4: Uploading your Smart Contract to the Blockchain was originally published in Lamden on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lamden TAU Token Swap FAQ

Jeff Scott — Thu, 27 Aug 2020 18:08:43 GMT

The token swap will begin on September 16th, 2020 at 4pm UTC, the day of the Lamden Mainnet release.

You can view a mainnet countdown timer at lamden.io.

FAQ

We have had a lot of questions about the token swap recently so lets address them all.

WHAT is a token swap?

The current circulation of TAU tokens are Ethereum based tokens called ERC20 tokens. The swap process allows you to turn your Ethereum ERC20 TAU into Lamden TAU.

Lamden TAU is used to pay for transactions on the Lamden blockchain.

WHEN will the token swap take place?

As stated above the token swap will not be active till the official Mainnet release which is September 16th, 2020 at 4pm UTC. No tokens will be swapped before the mainnet release.

WHERE will the token swap take place?

The token swap process is built directly into the Lamden Wallet.

You can download the Lamden Wallet here.

HOW long will the token swap be available for?

The token swap will be available for about 6 months after the Lamden Mainnet goes live. The exact date is not set in stone but will be communicated ahead of time.

Is token swap mandatory, or optional?

The token swap is MANDATORY. If you do not swap your Ethereum ERC20 TAU tokens during the 6 month swap window you will be unable to do so afterwards.

Do I need to swap ALL my tokens at once?

You can swap any amount of tokens during the swap period but you must eventually swap ALL of your tokens by the end of the swap window.

What happens if I miss the 6 month window? Do I lose TAU that was not swapped?

Once the swap window ends unswapped TAU will be stuck on the Ethereum Network.

Will X exchange support the token swap?

NO exchanges are taking part in the token swap. All swaps are manual and completed through the Lamden Wallet.
Your Ethereum ERC20 TAU will have to be moved from where you have it now to Metamask before you start the swap process.

The swap process cannot be started till Sept 16, 2020 at 4pm UTC and will be open for about 6 months.

What about my TAU in uniSwap liquidity pool? Do I need to take them out of the pool first?

Yes. To start the swap your Ethereum ERC20 TAU will need to be sent to Metamask.

Can I send my ERC20 tokens to the Lamden Wallet?

NO! Ethereum ERC20 tokens are NOT compatible with the Lamden Network. If you send your Ethereum ERC20 tokens to the Lamden Wallet they will be lost forever.

The only way to get your Ethereum ERC20 TAU onto the Lamden Network is by following the wallet token swap process.

The swap process cannot be started till Sept 16, 2020 at 4pm UTC and will be open for about 6 months.

What is dTAU?

dTAU is the name for Lamden’s TESTNET token and is only useable on the Lamden Testnet.

Why is the Token Swap active in the wallet right now?

The current swap function allows people to TEST the functionality by swapping Ethereum ERC20 dTAU to Lamden dTAU.

Ethereum ERC20 dTAU has NO VALUE just like Lamden dTAU.

Can I TEST the token swap function?

ERC20 dTAU exists on the Ethereum Kovan Network and you can swap it for Lamden dTAU which runs the Lamden Testnet.

Obtain some by asking an admin in the Lamden Telegram Chat Room for “ERC20 dTAU”. If you just ask for “dTAU” they will most likely try and send you Lamden dTAU; which is not what you want.
Have the admin send it to your Metamask wallet address; which you should provide to them.
Set your metamask wallet to the Kovan Network (dropdown at the top of Metamask popup)
Click the “Token Swap” menu option in the Lamden Wallet left-side menu.
Follow process to complete a swap

How do I know if I’m sending to an Ethereum address or a Lamden address?

Ethereum and Lamden addresses are quite different looking. You should NEVER send Ethereum directly to a Lamden address or Lamden to an Ethereum address.

Ethereum Address: 0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7

Lamden Address: 0000e9f4137969c4ee2fc047917dacd53aeb220fae0bdc87a82024c0ff3c9e50

What will happen to my Ethereum ERC20 tokens after the swap?

The Ethereum ERC20 TAU will be burned; never to be recovered again.

Where can I trade Lamden TAU after the swap?

The official exchange to trade Lamden TAU after you swap will be txbit.io. More to come on the official txbit.io listing in a later communication.

For more information, please visit:

Lamden TAU Token Swap FAQ was originally published in Lamden on Medium, where people are continuing the conversation by highlighting and responding to this story.

HTTPS for VPS as SubDomain and other Jargon

Jeff Scott — Wed, 17 Jun 2020 17:20:21 GMT

I ranted on twitter the other day about HTTPS being annoying

I got my answer so why not write about it!

Here’s how you do it

Basically my assumptions that Netlify would handle the HTTPS for me was incorrect even though their website lead me to believe it would, but that’s besides the point.

The only Netlify config needed was to point the subdomain to the Digital Ocean Droplet IP address in the DNS settings.

Setup A Record

Netlify just happens to host my DNS record. You add the same exact record on whoever hosts your DNS. “A Records” are a DNS standard and point a DNS name to an IP address. Which is exactly what I want.

Go to netlify DNS settings for your domain
Click Add new record
Fill in the information like so, making the value field the IP address of your VPS host (your digital ocean droplet or whatever you have).

Click Save

Install Let’s Encrypt stack on your VPS

Add repository and install package

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-nginx

The last command will walk you through some setup to create your certificate. Assuming the A Record was created, everything should go well.

Setup Nginx

This is really the meat of the whole setup.

What we want to have happen is nginx handle the HTTPS certificate on port 443 and then pass the request over to our webserver to handle it.

This is referred to as a proxy server.

so let’s create that server.

Remove the default NGINX server

rm /etc/nginx/sites-enabled/default

Create a new one

nano /etc/nginx/sites-available/proxy

Copy and Paste this code into it

server {
    listen 80;
    server_name sub.domain.com;
    location / {
        proxy_set_header   X-Forwarded-For $remote_addr;
        proxy_set_header   Host $http_host;
        proxy_pass         "http://127.0.0.1:18080/";

    }
    listen 443 ssl;

    ssl_certificate /etc/letsencrypt/live/sub.domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sub.domain.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

Change all 3 sub.domain.com entries to your specific url (no http or https!)
Change the port under proxy_pass to the local port of your web server
Save and close nano (ctrl-x, y, enter)
Make our new server live

ln -s  /etc/nginx/sites-available/proxy /etc/nginx/sites-enabled/proxy

Restart NGINX

sudo systemctl reload nginx

DONE!

Not so bad!

You should be able to browse to your DNS subdomain and your website should be served via HTTPS now.

This setup is particularly useful for serving APIs on HTTPS to avoid CORS errors from websites trying to consume your data.

A Frontend for your Smart Contract: Part B

Jeff Scott — Thu, 04 Jun 2020 18:27:08 GMT

3b: A Frontend for your Smart Contract

Part B

…this is a continuation from A Frontend for your Smart Contract : A

frontend/src/routes/users/[user].svelte continued

Our smart contract doesn’t just store balances. It also gives our users the ability to send tokens to other users by calling the “transfer” method.

In Part 2 we created an API endpoint to be able to call this transfer method and provide the arguments.

What we need now is a form on our website that lets the user fill in the required arguments (receiver and amount). And then we need to feed that information to the API.

This is the end goal. Let’s start by making the form section in the purple box.

This form contains 4 elements. A message and 3 input elements (two text boxes and a submit button)

Add the code in bold under the existing Token Balance

tag.

...
Token Balance: {value}


   Make a transfer

   To
   receiver} required="true"/>
   Token Amount
   amount} required="true"/>

...

Let’s take a look at the code we pasted in. It should look very familiar to the form code we created in Part 3A.

on:submit|preventDefault={transfer}>
   Make a transfer

   To
   type="text" name="to" bind:value={receiver} required="true"/>
   Token Amount
   type="number" name="amount" bind:value={amount} required="true"/>

Bind the form’s submit event to a function we will create later called transfer.

type="text" name="to" bind:value={receiver} required="true"/>

Create a text input box and bind its value to a variable we will create later called receiver.

type="number" name="amount" bind:value={amount} required="true"/>

Create a number input box and bind its value to a variable we will create later called amount.

In our JavaScript

...

   let receiver = "";
   let amount = 0;

Here we create our two variables to satisfy the bindings from the input boxes.

const transfer = async () => {

Here we define the async function that our form’s submit event will call.

const transaction = {
         sender: user,
         contract: 'my_token',
         method: 'transfer',
         args: {
            receiver,
            amount
         }
      }

This creates a transaction object that we will send to our contracting server API endpoint. This transaction object has all the information the server needs to process the transfer for us. Let’s break down the information.

sender: This is the account of the person who is SENDING the transaction. This becomes ctx.caller in our smart contract transaction method. If it’s been a while you should open the smart contract code and refresh your memory.
contract: The name of our smart contract. We set the API server up to process ANY smart contract. So, we need to tell it specifically which one we are trying to interact with.
method: Which method in our smart contract to execute. In this case our smart contract only has one method, but we still need to specify it.
args: The arguments to supply to the method being called. Specifically, the transfer method we designed takes two arguments, amount and receiver. It’s important here that we pass our variables with the correct names and types as to what our smart contract expects.

const options = {
   method: 'POST',
   headers: {
      'Content-Type': 'application/json'
   },
   body: JSON.stringify(transaction)
}

This is a standard object created to send a “POST” request. You can learn more about HTTP requests here if you’re curious, but it’s outside this tutorial’s scope. All you really need to know is to send data (our transaction object) to the API server we need to create a POST request. All our previous calls to the API server were GET requests which are generally used to GET information and are the default request type.

method: We want to tell the server this is a POST request. Our API endpoint is setup to expect this type of request (go back and look at the contracting server, “/” endpoint code to verify.
headers: We’re going to send a “Content-Type” header to tell the server what type of data we are sending so it can decode it on the other-side. In this case we are sending a JSON string, so we send ‘application/json’ as the type.
body: This is the main payload of our request in which we will send the transaction object we created above. We can’t send just the JavaScript object we have to encode it as a string. To do that we encode it as a JSON string which is a universally understood method of encoding. This ensures the server can decode the information properly on the other end. You can read up on JSON here if you are unfamiliar.

const res = await fetch(`http://localhost:3737/`, options)

Here we call fetch again and supply it with the URL of our contracting server then we feed the options object as fetch’s second argument.

Because we created transfer as an async function we have the ability to await the fetch request result and we store the result in the res variable.

const data = await res.json();

Just like we sent our data to the server serialized as a JSON string, the server sent us some data also serialized in JOSN. We can call the res object’s .json() method to decode that JSON back into a JavaScript object for us and we store it in a variable called data. The .json() method is asynchronous so we need to await the result, or our code will pass right by it before it’s finished decoding.

if (data.error) {
   alert(data.error);
}else{
   alert("You sent " + amount + " token(s) to " + receiver + "!");
}

Now we can look at the data returned from our API server and decide how we want to handle it.

This if statement looks to see if our data object has a property called error. We know that if our API server has an issue with processing the smart contract that it will pass that message back in the error property. If the error property exists, then we will create a browser alert box that will show that error to the user.

If there is no error property, then we can assume our smart contract completed. In a real blockchain situation we would get a success/failure status code back from our hash result to know for sure. But since smart contracts either fail or complete we can assume that if there was no error that our transaction was successful and pass the user a “success” message to let them know their transaction completed.

Now if you refresh your token site http://localhost:3000, log in as me, you should see this screen.

Well, all of our elements are there, but it’s pretty ugly. We need some styling. Add the following CSS between the tags. Then refresh your page.

...

...

Much better!

Let’s test. Type the word you in the To box. Type 100 in the Token Amount box and click the SEND button.

You should get this message.

That’s great! Everything is working perfectly so far. Let’s try and make a legitimate transfer now.

Type the word you in the To box. Enter 5 in the Token Amount box and click SEND.

This is great! We have confirmation that we sent 5 tokens to you.

But it’s not all perfect. When we click OK to close the popup the user interface still shows us we have 50 tokens. If we refresh the page, we will see the Token Balance is now 45. This is because the webpage updates the value again from the server when we manually refresh it. But it’s not a good design to ask the user to refresh the page every time they send a transaction.

Additionally, we should reset both input box values to get the user ready for a new transfer.

What should happen here, is that after the transfer is deemed complete, the webpage should make a request to the API server again to get the user’s new balance and display it.

We already know how to do this because we did it in the module before the page loads!

Let’s make a new function in our
...

This async refreshBalance function awaits the result of a fetch call to our endpoint just like we did in the module before the page was loaded. We can then update the webpages value variable with the value from the data response. Svelte will handle making sure that value gets re-rendered.

The second function we need to create is one to reset our bound input variables back to the defaults. Create this one under the refreshBalances function.

...
   const refreshBalance = async () => {
      const res = await fetch("http://localhost:3737/contracts/my_token/S?key=" + user)
      let data = await res.json();
      value = data.value;
   }

   const clearInputs = () => {
      receiver = ""
      amount = 0
   }

...

This clearInputs is NOT defined as async because we don’t need to await the result of anything.

receiver is a String type variable, so it’s default value is set to an empty string
amount is a Number type variable, so its default value is set to 0

Now let’s call these two functions under the success alert at the end of the transfer function so they are called on the event of a successful transfer.

...
      if (data.error) {
         alert(data.error);
      }else{
         alert("You sent " + amount + " token(s) to " + receiver + "!");
         clearInputs();
         refreshBalance();
      }
   }

   const refreshBalance = async () => {
...

Let’s try another transfer of 5 tokens to you and hopefully the page will re-render the token amount to 40 automatically.

Perfect! Everything is now working good from a UX (user experience) perspective.

The final thing we will add is a sign out button.

This will be almost identical to the sign in button created in Part A. We will use Sapper’s goto function to repoint the browser back to the sign in page.

Below our form add the following button element inside a new

tag.

...

   Enter Transfer Details

   To
   receiver} required="true"/>
   Token Amount
   amount} required="true"/>
   
      
      
   


...

This button has a binding on the click event to run a new function we will create called logout.

Add a statement at the top of the
...

Refresh the page and click the new sign out button
Sign in as user you and check their token balance. 10 whole tokens!

Finished!

You now have a fully functioning web frontend with a python smart contract backend.

You can check out the completed git repo for this part of the tutorial here.

What’s next?

Now that we have a tested and functioning smart contract with a functioning proof of concept frontend the next tutorials will be about adding the public blockchain to mix. This brings with it some new concepts, but I will tackle them one by one to make it understandable.

This is what to expect in the coming weeks:

Upload our working smart contract to the blockchain
Add user authentication via the Lamden Wallet
Accessing our smart contract variables from the blockchain. This is still going to be API driven but it will require just a slight modification to our code.
Creating transactions will be very similar to our API server requests except this time we will send them through the Lamden Wallet which will return our transaction results which we can process in largely the same way.

Check out Part 4: Uploading your smart contract to the blockchain

I’m available to chat on twitter, telegram or linkedIn

A Frontend for your Smart Contract: Part B was originally published in Lamden on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Frontend for your Smart Contract

Jeff Scott — Wed, 03 Jun 2020 18:17:17 GMT

3a: A Frontend for your Smart Contract

Part A

This tutorial is part of a series that demonstrates how to create a working application with Python contracting.

In previous tutorials we created a Python smart contract as well as an API dev server to interact with it.

Here are the previous two tutorials in this my_token series

Part 1: Smart Contracting with Python
Part 2: Python Smart Contract Dev Server

In this tutorial (Part 3a) we will install a frontend web framework called Sapper to create a user interface for our smart contract.

Setup

For this test we will use a simple lightweight framework called Sapper.

Dependencies

You will need the dependencies from the last two tutorials as well as these two new ones.

Install the latest NodeJs follow instructions on the NodeJs site.

Install Sapper:

With NodeJs installed; go to your my_token project directory and type this command.

npx degit "sveltejs/sapper-template#rollup" frontend
cd frontend
npm install

Now let’s test that we can view the Sapper test site.

Enter the below command from the frontend directory

npm run dev

Open your internet browser and go to http://localhost:3000

If you see this page load, then Sapper is up and running!

The Sapper starter template comes with a bunch of files we won’t need for our project and there are some files we need to create and edit.

Follow these steps to organize our project.

Overwrite the files in frontend/static/ with these files

Save then to your computer then copy them to the folder

2. Delete this folder (and all files in it)

frontend/src/routes/blog

3. Delete these files

frontend/src/routes/about.svelte
frontend/static/successkid.jpg

4. Create this folder

frontend/src/routes/users

5. Create this file

frontend/src/routes/users/[user].svelte

5. Edit these files

frontend/package.json

"name": "my_token",
"description": "A simple smart contract tutorial",

frontend/static/manifest.json

"background_color": "#A1A0C926",
"theme_color": "#5F5E9D",
"name": "My Token",
"short_name": "My Token Tutorial Project",

6. Replace ALL the code in these files with the code provided

frontend/src/components/Nav.svelte




   
   My Token

frontend/src/routes/_layout.svelte

frontend/src/routes/index.svelte






   My Token


Welcome to My Token

7. Restart the Sapper dev server

From your command prompt do a control + c to stop the dev server and then enter this command to start it again.

npm run dev

Now when you navigate your browser to http:localhost:3000 you should see our starter My Token website!

**You may need to hold shift and click refresh to get the style sheet to reapply.

The Svelte framework

Sapper is a Single Page Application (SPA) implementation of Svelte. Svelte is a web framework that makes organizing our programming logic very easy as we can keep all the JavaScript (logic), CSS (styles) and HTML (markup/layout) in one file.

Svelte allows us to create “responsive” code, which mean our webpage can easily respond and update to user interactions. By using Svelte we can get a surprising amount of functionality out of a website without using boilerplate logic (code that is native to a framework but not native to JS, CSS or HTML) or needing a Virtual DOM.

I mention this only because the files we will be editing have the extension “.svelte”; which could be different if you have made websites previously. When we build our project Svelte automatically compiles these files into the necessary .html, .js and .css files to make a fast and responsive static website.

frontend/src/routes/index.svelte

Right now, our site has a Navbar Icon and a nice greeting. What we need now is a login box and a sign-in button.

We will do this by adding a form to our index.svelte file.

Add the following code.

...


Welcome to My Token


   Check your token balance

This will add the necessary HTML to render us

a message
an input box that the user can type in
a sign in button they can click.

If your refresh the website, it should now look like this now.

** Sapper will automatically refresh the webpage when you save your changes. But I mention “refreshing” just in case it fails to.

It looks great but nothing happens when we click the button! So, let’s add some interactivity.

We need our website to capture the username typed in the box, so let’s wire it up to a variable. Add the following code in bold to the input box.

...
Check your token balance

bind:value={user} required="true"/>

...

This will BIND the value of the input box to a variable we called “user”.

We don’t have a user variable defined yet, so let’s add that JavaScript between our

Now our webpage can track the user input in the box. To prove it lets output the value of our user variable to the webpage.

Add this code under the h1 tag near the bottom of our file.

...
Welcome to My Token

{user}

...

When we use these bracket in our HTML it allows us to render JavaScript on the webpage. It’s a good way to display the value of variables our webpage is keeping track of. {user} will output the value of our user variable, which is being updated every time the user types in the box.

Refresh the webpage and type your name in the box, you should now see the webpage render what you are typing in real-time. Cool!

Okay, as cool as that is, we don’t need to display the name there. This was just to illustrate that our variable is being updated (bound) to the value of the input box.

Go ahead and remove the

{user}

line from our code we just added.
...
Welcome to My Token

...
When the user hits enter on the keyboard with the cursor in the input box, or clicks the button, the form will attempt a submit event. We need to bind the triggering of that event to a function that will login the user.
Add this event binding inside the form tag

...
on:submit|preventDefault={login}>
   Check your token balance

   
...

on:submit tells Svelte we want to bind to the submit event when it’s triggered.

|preventDefault tells the webpage to ignore the default behavior of this event.

={login} tells the webpage to instead run our custom function called “login”.

Let’s now go back to our JavaScript
...

This line is our import statement to make the Sapper goto function available.

import { goto } from '@sapper/app';

This is our login function definition. As you can see, we are calling the goto function and passing it the new route we want our webpage to render.

const login = () => {
   goto('/users/' + user);
}

‘/users/’ + user will concatenate the string value “/users/” with the user variable we made earlier. This will create the dynamic route that Sapper will render for us. So, if the user entered the name “byron” then Sapper would attempt to take us to the route http://localhost:3000/users/byron.

Save your index.Svelte and refresh the webpage.

Enter a username and click sign in. Notice the address bar updates with our route, including the username. I’m sure you also see that the page is blank. That is because we haven’t created this route yet, but we will now.

frontend/src/routes/users/[user].svelte

For a browser to render a route it needs the html file to be served to it from the web server. In this case the browser is asking our web server at http://localhost:3000 for the html file associated with the route/users/me.

We’re good, but we could never create 1 html file for every possible username. That would take too much time. Luckily Sapper can create these html files dynamically for us and send them to the browser.

When the browser passes the route into to Sapper it will take the last part of the route and make a variable, we can access in our JavaScript. Then we can use that variable to render information about the user on the webpage.

Sounds more complicated than it is, because Sapper makes it easy.

Sapper takes the first part of the route /users/ and looks for a folder under frontend/routes that matches. In this case we created this folder during our setup in step 4.

The [user] part of our filename tells Sapper what we want the variable to be called in our file. Sapper then takes the last part of the route, me, and passes it into our file. We created this file during our setup in step 5.

This is again a regular Svelte file, but with one addition, a module declaration.

Paste this code into frontend/src/routes/users/[user].svelte. Most of it should look familiar to your from the last file, except now we have this extra

{<em>user </em>+ "'s Tokens"}

{"Hello " + user + "!"}

Refresh your page and you should now see this.

This is looking great. We changed the tab name to include the username we also included a personalized greeting.

How does this work? Well our module runs first, and the Sapper preload function within it gets passed the params object. One of the properties of this object is our “user” value. So, params.user, in the picture above would have equaled “me”. The return statement from the preload function gets passed to our regular

...

There is a lot going on here, depending on your expertise you’ll understand all of it or none if it.

export async function preload({ params, query })

This line defines the preload function, which we talked about already.

const res = await this.fetch("http://localhost:3737/contracts/my_token/S?key=" + params.user)

On this line we call this.fetch (a wrapper around node’s fetch utility), to get the user’s token balance from our smart contracting server. The value being passed to this.fetch is our API route, created in the last tutorial; with the user concatenated to the end to become the “key”.

*This is probably a good time for you to check if the contracting server we created last tutorial is started.
You can copy and paste http://localhost:3737/contracts/my_token/S?key=me into your browser to validate your contracting API server is working correctly, you should get { “value”: 50 }.

The response object from this.fetch will be stored in the res variable and the await command makes the code wait here for the response before continuing.

const data = await res.json();

This line gets our JSON data from the body of the response object and stores it in a variable called data so we can use it.

if (data.value !== 'undefined') this.error(res.status, data.message);

This is a check to make sure our request was successful. If we didn’t get a “value” passed back in the response, then show the error page because something is wrong.

if (data.value === null) data.value = 0;

If we did get a value, but that value was “null” then make it zero.

Our contracting server is setup to return “null” for any value not found in state.

In this case null will be returned for any user that never had tokens. If they had tokens, but transferred them all away, then they would get a value of 0 returned instead of null.

return { value: data.value, user: params.user };

Now our module is going to return TWO things,

user: the username from the prefetch params object
value: number of tokens returned from our API server.

We can use this new value variable in our


   {<em>user </em>+ "'s Tokens"}


{"Hello " + user + "!"}


   Token Balance: {value}

...

Refresh the page and you should now be displaying token values.

This tutorial has run longer than I expected and ended up being more of a webpage creation tutorial than I wanted to write.

I think it’s all good information and so instead of editing it down I’m going to make this a two-parter. Part B should be out tomorrow.

You can check out the git repo for this part of the tutorial here.

>> PART 3b-A Frontend for your Smart Contract Cont.

Recap

Creating a website with Sapper and Svelte is easy
Displaying information from a smart contract via API is also easy!

I’m available to chat on twitter, telegram or linkedIn

A Frontend for your Smart Contract was originally published in Lamden on Medium, where people are continuing the conversation by highlighting and responding to this story.