You are on page 1of 7

Technical

Whitepaper:
Tokit.io

Document purpose
The purpose of this document is to present a detailed technical
description of the SingularDTV Decentralized application, Tokit.io. It will
explain the purpose and features of the system, the interfaces of the
system, what the system will do, the constraints under which it must
operate and how the system will react to external stimuli.

Scope of Project
The S-DTV Tokit.io (the platform), is a multi-layered system that allows
considerable flexibility and decentralization in funding and monetizing
entertainment products such as movies, TV shows and music - any
piece of entertainment or IP that can be digitized in a decentralized
way, using blockchain technology.
To achieve this, the platform provides the following functionalities
through its different interconnected modules, that provide:

• Wallet management

• User authentication

• Project creation
• Ethereum Smart Contract System (SCS) deployment for each
project
• Rights Management Mechanisms

• On-chain payment processing

• On-chain token (project) registry


II. Overall Description



This section gives an overview of the functionality of the platform, and
the algorithms and processes that it uses to perform them.
In the
following sections, whenever the term “client” is used, it refers to the
front-end application either in the user’s browser, or standalone app on
user’s device.
This is a very high-level overview of the general architecture of the
platform:


Wallet Management and User authentication
Since many parts of the platform operate on the blockchain, funds
never flow through our servers. In order for our users to be able to
interact with the Ethereum blockchain, they need a private key. Our
interface allows them to generate one locally, in their browser without
touching our servers, and then encrypt that private key with password,
and download it in a special file called “wallet”.
We provide recovery mechanisms through a 12-word mnemonic
phrase, using BIP32 and BIP39
User’s public key and address are derived from their private key. Once
the wallet is created or imported in our front-end application, the user
can interact with the Ethereum blockchain. Ethereum addresses are
160 bit values represented in 40 characters long hexadecimal format.

Some of the functionalities of our platform are centralized (off-chain,


with traditional servers and SQL databases), and some on-chain. This is
to ensure a trust-minimized solution, while having some of the
performance benefits of a centralized approach.
In order for our servers to authenticate a wallet holder, the user needs
to prove they have access to the private key of their address. Here’s
how we do that:

• The client (front-end) asks the server for a challenge phrase to


sign

• The server creates a session and generate a random 36 characters
long string a challenge;
• Returns the challenge phrase and session id to the client.
• The client signs the challenge phrase using Elliptic Curve Digital
Signature Algorithm or ECDSA and sends the signature, session id
and its address to the server for verification
• The server verifies the ECDSA signature against the claimed
address, and if correct, authenticates the session id.
• After this back and forth hand shake, the session_id is considered
authenticated by the server, and the client will include it in the
header in all future requests.

Project management, SCS deployment, Token


Management
Tokit allows each user to create “Projects”.
A project is an entity that has some elements off-chain and some on-
chain.

Off-chain it has:

Name
Description
Owner (for listing purposes)

On-chain it has a set of smart contracts that are deployed on Ethereum.


We call them SCS. Entities can interact with these smart contracts
either through our UI or programmatically directly with the Ethereum
blockchain. Each deployed smart contract has a unique address on
Ethereum, and an ABI that describes its functions and attributes.
A) An ERC20 Token contract with extended functionality. These tokens
will be the foundation of our platform. They enable synergies within all
our modules, and even external 3rd party applications built to work
with this type of token contract.
This is the smart contract that acts as the token ledger. Internally it
stores the amount of tokens each address holds in an attribute named
mapping (address => uint256) balances, and through its different functions,
tokens can be transferred from one address to another
The extended functionality is what makes these tokens special: they are
connected to the Rights/Rewards smart contract described next.
B) Rights/Rewards smart contract. Fundamentally, this smart contract
acts like a value bucket. Any entity can add ETH (Ethereum’s native
token), or other ERC20 tokens to this bucket. Only token holders can
withdraw value from this bucket, proportional to the number of tokens
they hold.

C) Token launch smart contract: project owners can choose to launch


their project tokens to the world. This smart contract handles the logic
necessary for exchanging ETH (native Ethereum token) and project
tokens. At the time of its creation (deployment), the owner allocates a
number of tokens to it, and specifies the price in ETH (or a specific
ERC20 token) of each token. Any entity (address) that sends funds to
this contract will receive project tokens in exchange. After the launch is
successfully over, it will send the resulting funds to the beneficiary
address (usually the owner, unless otherwise specified during the
creation, by the owner). In case it fails (minimum threshold set during
the creation is not reached), any entity that participated can recover
their funds. It has the following important functions:
Tokit deploys the first 2 contracts on the Ethereum blockchain for every
project created through its interface, in exchange for a fee, payed in
USD, ETH, or SNGLS (SingularDTV’s ERC20 token).
When a user chooses to create a project, the front-end app takes them
through 3 steps:
1. User is prompted for the project name and description
2. User is prompted for token parameters: Name (e.g.Quantum),
Abbreviation (aka Token Symbol, e.g. QNTM), and Total amount (e.g.
1,000,000).
3.User chooses a payment method and confirms payment
If the payment is done using USD, a payment token is given to the client
by the payment gateway (e.g. Stripe).
If the payment is done using ETH or SNGLS, a transaction receipt is
returned to the client by our payment smart contract. The client sends
the transaction directly to our payment processor smart contract. No
tokens touch our servers at any point in time.

The payment receipt is sent to the server alongside all the collected
information about the project:
The server verifies the payment, and if ok adds the project creation into
a job queue and returns a job id to the client.
The creation job runs:

1. Add an entry to our SQL data base with the project, and flag it as
pending. 


2. Deploy the 2 Smart Contracts (Token and Rights), with the given
parameters. All the created tokens are allocated to the user
(project creator). 


3. Once the deployment is done, register the 2 contract addresses in


our database, in 
effect linking it to the project owner (for listing
purposes only). 


4. Send a transaction to our registry smart contract and register the


2 newly created smart contracts to user’s address. This step
ensures an immutable record of every created SCS exists on the
blockchain. 


The client will verify the job creation until it’s done (it may take a few
minutes to deploy everything on the blockchain). Once the creation is
done, the user will see the newly created project in their dashboard UI.

The user can now transfer his newly created tokens to any ethereum
address, using our wallet interface. Since the tokens are directly linked
to Rights/Rewards aspect of the platform, this transfer of tokens
represents transfer or rights, effectively turning tokit into a Rights
Management Gateway. This is a simple and elegant, yet very powerful
solution, to a very complicated problem.
As seen in the description, Tokit is a hybrid application, with some
functionalities performed by our back-end server(s).
It needs 2 global
(as opposed to per-project) smart contracts to function properly:

Payment processor smart contract (mentioned earlier). To process


payments made in ETH and SNGLS. This smart contract acts as an
escrow. The user sends their ETH or SNGLS to this smart contract. This
smart contract holds their tokens and registers their payment. After our
backend server completes their project creation job, the smart contract
sends the fund to SingularDTV’s cold storage and marks user’s payment
as “used”. We use this payment mechanism in order to make
everything as asynchronous as possible, and prevent user fund losses in
case of browser crashes or any other technical problems on user’s
end.


Project registry smart contract. Whenever a new project SCS is created,


we register that into this registry. Our front-end app gets the list of
current user’s projects from this registry. The reason we use this as
opposed to just our SQL database is to make our platform more
decentralized, and less prone to censorship.

***

You might also like