Analog: The Decentralized Timegraph

Timepaper (Version 2.0)

March 2022
Executive Summary
Analog is the world’s first proof-of-time (PoT)-based and omnichain protocol that
allows decentralized applications (dApps) to communicate frictionlessly through
validated event data. The PoT consensus protocol incorporates various technologies
such as verifiable delay function (VDF), ranking score, and fixed stake to validate event
data. With PoT, all nodes have a fair chance of being selected to participate in
interoperability consensus. This contrasts with proof-of-work (PoW)-powered networks
that require computationally-intensive resources to mine blocks or proof-of-stake
(PoS)-enabled networks where nodes must stake enough coins. When combined with
threshold signature schemes (TSS), Analog’s PoT consensus protocol provides a
complete decentralized and secure interoperability solution, unlike most solutions that
are largely centralized and have single point of failure ( SPOF). For example, any node
can join the network and participate as a tesseract in cross-chain communication.
Similarly, any node can also join the network and propose or confirm blocks to the
Timechain. The PoT protocol also combines Byzantine consensus, cryptography, and
incentive mechanisms to achieve safety, persistence, and liveliness requirements that are
unique for omnichain communication. Most importantly, the Analog Timegraph
leverages zero-knowledge proofs (ZKPs) to create a validated pipeline of event data that
platform builders and dApp developers can privately leverage to power the next
generation of cross-chain applications.

2
CONTENTS

Executive Summary 2

1.0 Introduction: Event Data and Cross-chain Communication 6

1.1 Introducing Analog 8
1.1.1 What Is Event Data? 8
1.2 Value Proposition 9
1.2.1 Our Vision 9
1.2.2 Objectives 10

2.0 Interoperability on the Analog Network 11

2.1 Threshold Signature Schemes 11
2.2. Decentralized Consensus 12
2.3 Gateway smart contracts 12
2.4 Timegraph API and Developer Tools 13
2.5 Analog Interoperability Stack 13
2.6 Generic Cross-Chain Event Data Transfer Protocol 15

3.0 Nodes 18
3.1 Publishers 18
3.2 Time Nodes 18
3.3 Time Electors 19
3.4 Tesseract Nodes 19

4.0 Proof-of-Time Primitives 19

4.1 Fixed Stake 20
4.2 Verifiable Delay Function 20
4.3 Participation Keys 21
4.4 Trust Index 22
4.5 Ranking Score 23
4.6 PoT Workflow 24
4.6.1 Block Proposal 24
4.6.2 Block Confirmation 25

5.0 Security Architecture 27

3
5.1 Safety Guarantees 28
5.1.1 Safety Analysis 28
5.1.1.1 Safety Incentive Mechanisms 29
5.2 Liveness Guarantees 30
5.2.1 Liveness Analysis 30
5.2.1.1 Liveness Incentives 30
5.3 Attack Vectors 31
5.3.1 Sybil Attacks 31
5.3.2 Bribery Attacks 31

6.0 Zero-Knowledge Proofs 32

6.1 zk-STARKs Workflow 33
6.2 zk-STARKs Use Cases 34

7.0 Gateway Smart Contracts (Continuum) 35

8.0 Event Data Marketplace 35

8.1 Timegraph API 38
8.2 Use Cases 41
8.2.1 Decentralized Finance 41
9.2.1.1 Decentralized Money Markets 41
8.2.1.2 Decentralized Exchanges 42
8.2.1.3 Stablecoins 42
8.2.1.4 Yield Markets 43
8.2.2 Metaverse 44
9.2.2.1 Off-chain to the on-chain transfer of metaverse assets 44
8.2.2.2 On-chain transfer of NFTs from one game to another 44
8.2.2.3 Cross-chain transfer of NFTs 45

9.0 Analog Economics Overview 46

9.1 Tokenomics Actors 46
9.1.1 Publishers 46
9.1.2 Subscribers 47
9.1.3 Time Nodes 47

4
9.2 Token Specifications 48
9.3 Staking 49
9.4 Token Distribution 49
9.5 Governance 51
9.5.1 Participants in Analog Governance 52
9.5.2 Process 52
9.5.3 Referendum 52
9.5.4 Voluntary Locking of Tokens 56

10.0 Tentative Roadmap 57

11.0 Community 59

12.0 Our Team 60

Legal Disclaimer 61

5
1.0 Introduction: Event Data and Cross-chain Communication
Virtually all the dApps allow users to perform certain actions within their ecosystems.
These activities can be as ingenious as a user purchasing a non-fungible token (NFT) or
moving assets from one wallet to another. The actions could also be as complex as
staking tokens in liquidity pools (LPs) across multiple chains to maximize yields.

Irrespective of the level of complexity or what the user uses the dApp for, every action
they undertake constitutes event data. Despite event data occurring across virtually all
these applications, there is no mechanism to leverage it for cross-chain communication.
Because of the weak assumptions about event data, current dApps mainly operate in
siloes without an interoperable framework, similar to the early web 2.0 systems that
worked without notification mechanisms.

The inability to share event data across different networks has led to inefficient systems.
Take the example of an entity owning event data on chain A and looking to transact that
data on chain B. There are three primary cross-chain scenarios.

The first approach involves using bridges that allow the crypto asset to be
locked/burned on one chain and an identical (wrapped or synthetic asset) to be
unlocked/minted on the destination chain. Ultimately, the user would have to manually
convert the wrapped asset to access a native token on the destination chain, often at
exorbitant fees. This approach is not only centralized but also requires substantial
engineering efforts to scale, especially when connected protocols change or new ones
emerge.

The second approach involves using oracles. At the outset, oracles are simply off-chain
nodes that provide an intermediary layer between real-world data and on-chain smart
contracts. Since the oracles are off-chain, they operate primarily as intermediaries
(trusted nodes), which goes against the Blockchain’s core principle of decentralization.
Oracles are also data source agnostic leaving the genuine data providers from the
interoperability equation.

6
The third approach (and which is emerging as the leading go-to solution) is the use of
sidechains or hubs. Under this framework, sidechains—which can be sovereign
chains— operate largely as layer-2 protocols that are compatible with the hub (single
mainnet). For example, Cosmos-based chains (also called zones) can use the
inter-blockchain communication (IBC) protocol and transfer value by leveraging the
Tendermint consensus.

Polkadot has a similar structure to Cosmos, albeit with slight differences. Sovereign
chains—also called parachains—use bridges to connect to the Relay Chain. Parachains
can also communicate through a cross-chain messaging communication protocol
(XCMP). Despite the popularity of these ecosystems, their infrastructure largely
promotes centralization because users cannot seamlessly transfer assets outside of their
ecosystems.

For example, transferring an asset from a non-Cosmos-based or Polkadot-based

network still requires a smart contract-based bridge mechanism. Sidechains are also
limited by the PoS consensus, which can be sluggish with significant barriers to entry
for validators.

To eliminate these interoperability challenges, the Analog network leverages validated

event data to achieve seamless cross-chain communication. We believe that a truly
decentralized consensus mechanism is necessary to address the challenges that bedevil
the bridges, oracles, and sidechains.

That is why we have built the PoT consensus protocol from the ground up. At the
outset, the PoT leverages a ranking score, fixed stake, and VDF (described later in
subsequent sections) to address the major challenges that PoS-enabled interoperability
solutions often face.

When used alongside block pipelining, PoT can minimize messaging overheads in
byzantine fault-tolerant (BFT) replicated state machines and achieve sub-second finality
times in cross-chain communication.

7
To address security, we have incorporated TSS where more than 90% of tesseracts
(discussed later) have to attest to any cross-chain transaction to be considered valid on
the Analog network.

1.1 Introducing Analog

Analog is a PoT-powered, trustless, and omnichain network that allows dApps to

communicate seamlessly across different chains. Analog creates a scalable and
high-performant ecosystem where tesseracts and time nodes (described later in
subsequent sections) provide an open and decentralized infrastructure for cross-chain
event data transfer.

For example, platform builders can easily plug in their sovereign chains to all other
ecosystems. Similarly, dApp developers only require one simple application
programming interface (API) to communicate and access global liquidity within the
entire Blockchain ecosystem.

Besides platform and dApp developers, the Analog network allows users to consolidate
fragmented liquidity as it allows transactions to flow freely between heterogeneous
chains. With Analog network, dApp builders and users have access to a trustless,
omnichain network that unlocks fragmented liquidity across multiple chains.

1.1.1 What Is Event Data?

In the traditional web2 world, applications often use event data to capture and describe
what is going on at a specific time. For example, the event data in these applications
could be used to detect specific events, debug the applications, or even notify users that
something has occurred.

Like it is useful in web2 applications, event data can also become a valuable tool for
dApp builders that write or users who interact with smart contracts. For example, an
event data like a new token transfer on the Ethereum network can be useful in many
applications, such as:
8
● Alerting users that they have received tokens from their wallet interfaces.
● Triggering asset transfers across different networks if the token was locked or
burned on the Ethereum network.
● Swapping NFTs between different chains via a universal wallet. Users could even
use NFTs on one platform as collateral for a loan in DeFi applications on any
chain.
● Allowing dApp developers to build gaming applications that would enable
players to move between different games on heterogeneous chains, carrying their
unique assets with them.

In the context of the Analog network, event data is any data within smart contracts or
dApps that developers or users want to capture and use to trigger actions in other
applications.

1.2 Value Proposition

Blockchain innovations are still in infancy, and breakneck competition is essential for
the ecosystem’s growth. However, today’s Blockchain ecosystem is subject to the same
pressures that the early internet had in the 1980s and 1990s, and balkanization risks are
imminent.

At Analog, we believe platform builders, dApp developers, and users can only realize
the true potential of Blockchain if an interoperability framework exists to connect
multiple networks. We also believe that event data is the lifeblood of many dApps that
want to unlock liquidity across multiple chains.

1.2.1 Our Vision

Our vision is to create a decentralized interoperable protocol that leverages validated

event data. We want to become a predominant protocol and language for recording and
transferring event data with thousands of developers leveraging the Timegraph API to
build next-generation dApps.

9
1.2.2 Objectives

The primary objectives of the Analog network are threefold:

● To create a chain agnostic interoperable platform. Our goal is to create a

proven, secure, scalable, and omnichain Timegraph that organizes the dApps’
event data, making it accessible and useful. Developers can use the Analog
network to build cross-chain dApps without sacrificing trustlessness and
easily transfer tokens, send messages, and initiate call-to-actions (CTAs)
across various networks.

● To create an event data marketplace where subscribers and publishers

interact in an open and transparent manner. The Analog Timechain is a
universal ledger consisting of validated event data that developers and users
can access through a simple and easy-to-use Timegraph API.
● To safeguard user data privacy. The Analog network uses zero-knowledge
proofs (ZKPs) as a mechanism to preserve data privacies on the platform.

10
2.0 Interoperability on the Analog Network
We have designed the Analog network as a “Blockchain of Blockchains” with the notion
that no single decentralized platform can solve everything. In this regard, Analog
allows sovereign Blockchains—each with its own consensus protocol, use case, design,
and tokens—to seamlessly interoperate while benefiting from the network’s scalability
and security.

The Analog network has four essential components that allow it to deliver seamless
interoperability:

2.1 Threshold Signature Schemes

The protocol relies on threshold signature schemes (TSS) where a group of

tesseracts—special nodes that participate in the interoperability processes—jointly
compute a public key and secret shares (private keys) that are never revealed during the
computation processes. Tesseracts act as decentralized observers (listeners) on external
chains and can achieve consensus on the relevant state of these chains via a distributed
key signing in a TSS process.

The tesseracts collectively hold standard Schnorr signature keys for authenticated
interaction with external blockchains. These keys are distributed among multiple
tesseracts so that only a supermajority (more than 90%) can sign any cross-chain request
on behalf of the network. At no time does the network allow a single tesseract or
minority of nodes to piece together the private key and sign cross-chain requests on
behalf of the whole network.

The key generation ceremony and signing mechanisms are done via multi-party
computation (MPC) processes that reveal no secret of any participating tesseract.
Because the decentralized tesseract system can hold a single TSS key and address, the
network can support smart contracts and manage vaults or liquidity pools on virtually
any connected chain. To ensure economic safety, each tesseract is required to stake an
11
equal number of tokens in the network. The bonded tokens—which we also refer to as
the fixed stake—are subject to forfeiture upon tesseract failure or malfeasance. In the
blockchain context, this mechanism is often known as slashing.

2.2. Decentralized Consensus

The network is supported by a decentralized set of time nodes (validators) that validate
and append event data to the Timechain. Time nodes are responsible for generating the
blockchain and maintaining the replicated state machine. Each time node can vote on
block proposals with voting power proportional to the ranking score that the node has
accumulated in the network.

Time nodes need to be online (active) at all times, ready to participate in the consensus
process. Time nodes are incentivized for each block they add to the Timechain. Like
tesseracts, each new time node is required to lock an equal number of tokens in the
network as a bootstrapping mechanism. Once the node has participated in at least one
consensus round, the network begins to rely solely on the ranking score as a parameter
for validation processes. The locked tokens are subject to slashing upon time node
failure or malfeasance behavior.

2.3 Gateway smart contracts

The gateway smart contracts connect tesseracts and external layer one chains.
Whenever there is a request for event data from an external subscriber, any tesseract can
listen to events occurring on external chains and fetch it across the Analog Gateway
application programming interface (API). However, before the transaction is
transmitted to the Analog network, more than 90% of tesseracts connected to the same
network have to attest to it in a TSS process.

The fetched event data is then validated on the Timechain, allowing tesseracts to use it
as a basis for writing to the destination chain’s gateway by executing a cross-chain event
data transfer (XCEDT) function call.

12
2.4 Timegraph API and Developer Tools

The Timegraph API and software development kits (SDKs) sit atop the decentralized
network and gateway smart contracts (application layer) and allow dApp builders to
compose applications across any two chains in a single hop. It also provides a unified
and easy-to-use access point where users can query any data from external chains. The
Timegraph API and SDKs add universal interoperability to the Analog network as
application-layer solutions, allowing dApp builders to compose cross-chain
applications.

2.5 Analog Interoperability Stack

At an abstract level, the interoperability stack is a four-layered solution as shown below:

13
Figure 1: Interoperability stack

The Analog network has four primary layers:

● Chain layer. This layer consists of multiple sovereign Blockchains that the
Analog onboards on its network. As a chain agnostic platform, the Analog
network will onboard EVM-based, Cosmos-based, and Polkadot chains via a
simple SDK that any tesseract can download and install.

14
● Tesseract layer. This is the core layer within the network that facilitates
monitoring and message passing in cross-chain transactions. The Tesseract nodes
are the primary actors within this layer that ensure trustless interoperability
between multiple chains.
● Consensus layer. The Analog network is completely decentralized, unlike
centralized or federated bridges that require a trusted third party for the
cross-chain transfer of assets. The platform relies on decentralized time nodes to
confirm the fetched event data in a completely trustless manner.
● Timechain. This is the heart of the network that stores confirmed event data
emanating from multiple chains.

2.6 Generic Cross-Chain Event Data Transfer Protocol

The core of the platform’s interoperability feature is a generic cross-chain event data
transfer (XCEDT) protocol. The XCEDT protocol sits atop the permissionless network
(tesseracts and time nodes), which provides routing and validation services. It is a
generic messaging protocol that allows any dApp developer building on one network to
call and use any function on other connected networks.

By leveraging the XCEDT protocol, the platform provides complete composability

across the web3 ecosystem. For example, dApp builders can select the blockchain best
suited for their use cases and build a cross-chain solution that offers users a seamless
and one-click experience, allowing them to interact with any asset on any network.

The tesseracts serve as byzantine fault tolerant (BFT) notaries that attest to the validity
of cross-chain requests/event data from the source chain (A) to the destination chain (B)
in an XCEDT protocol. They also relay these messages across the network. The
destination chain’s smart contract needs to whitelist the TSS address of the tesseract
network to trust that the Analog network has verified event data on the source chain.
This allows conditional execution on the destination chain’s contract depending on
cross-chain requests from the source chain.

15
Figure 2: High-level illustration of XCEDT protocol

An essential feature of the XCEDT protocol is that the cross-chain request can be
attached with a value in the form of tokens ($ANLOG token in the case of the Analog
network) that considerably enhances the composability of dApps across different
networks. The messaging layer of the XCEDT protocol consists largely of interface
smart contracts on the Analog-connected chains.

A dApp developer needs to deploy a contract on the source and destination blockchain
to access this layer. On the source chain, the sending smart contract invokes the
send_message ( ) function with the following information:

● Sender’s contract address

● Destination chain ID
● Destination smart contract address
● $ANLOG tokens to transfer
● Gas limit on the destination chain
● Contract message (memo) for the destination transaction

The sending smart contract must also implement the revert_message ( ) function that
can be called by the tesseract network any time the delivery of the message or

16
transaction on the destination chain fails. For example, the revert_message ( ) function
can be called whenever the destination chain’s vault is out of funds, out of gas, or
invalid messages.

Upon detecting failure, the Analog network refunds the $ANLOG tokens to the
sender’s address (less gas fees). This triggers the revert_message ( ) function, which
reverts to the dApp actions—including unlocking assets or non-fungible tokens (NFT).
On the destination chain, the smart contract must implement execute_message ( ) that
takes the same parameters as the send_message ( ) function and performs the
application logic.

Below are the steps involved in such a process:

1. A user initiates a message transfer function (send_message ()) from the

source chain by specifying the destination address and other details.
2. The Analog Gateway API gets activated
3. Any tesseract node connected to the source chain can fetch this request
and transmit it across the gateway API. However, before the request is
sent to the Analog network, more than 90% of tesseracts connected to the
same chain must attest to the cross-chain request by partially signing it in
a TSS process.
4. If more than 90% of these tesseracts attest to the cross-chain request, the
transaction undergoes a PoT consensus on the Analog network where it is
confirmed on the Timechain.
5. Once confirmed on the Timechain, the Analog network subtracts the
transaction fees (in source chain tokens) and prepares an ongoing
transaction to the destination chain (specified by the destination address).
6. Suppose 90% of tesseracts connected to the destination chain attests to the
confirmed transaction. In that case, the token transfer call emerges from
the Analog Gateway and runs the execute_message ( ) call, completing the
XCEDT process.

17
3.0 Nodes
The Analog ecosystem is comprised of four categories of nodes that collaboratively
work together to achieve the network’s goals:

3.1 Publishers

A publisher is any node that submits event data to the Analog’s marketplace. Once
validated and appended to the Timechain, subscribers (consumers) can use the
publisher’s event data to power cross-chain applications, microservices, and other
intelligent data pipelines.

Analog network has an inbuilt tokenization model for event data monetization that
incentivizes publishers' participation on the platform. For example, their trust indices
(described later) are automatically increased as they earn direct revenues from
subscribers.

3.2 Time Nodes

A time node is any node on the network that confirms blocks to the Timechain. Like
time electors, the authority of time nodes to confirm blocks emanates from their ranking
scores and fixed stake (described later).

The higher the ranking score a time node has, the more likely it will be selected to
confirm blocks provided they have staked an equal amount of tokens in the network.
During each slot, every time node runs a VDF-based lottery scheme to decide whether it
has been selected to participate in the consensus process.

3.3 Time Electors

A time elector is a special time node that proposes blocks to the Timechain. The
probability of becoming a time elector is proportional to the fixed stake and a ranking

18
score, i.e., the higher the ranking score (described later), the higher the chances of
becoming a time elector.

The network expects one time elector to propose a block at any given slot time. This
ensures that the other time nodes in the ecosystem can replay identical copies of the
Timechain.

3.4 Tesseract Nodes

Tesseract nodes are special nodes that fetch event data from external chains. Any node
can join the network as a tesseract and fetch event data from external networks. A core
component of tesseract nodes is that they rely on TSS protocol where more than 90% of
tesseracts have to partially sign the event data for the cross-chain transaction to be
transmitted across the Gateway API.

4.0 Proof-of-Time Primitives

PoT is a completely decentralized consensus algorithm where any node (user) can join
and propose/confirm blocks without being hindered by the hardware or money. It
works by selecting validators based on their ranking scores and fixed stake. A ranking
score is a numerical weighting measure that the algorithm assigns to each validator
based on its historical experience (the accuracy with which the node validates event
data) and other validators’ experience with the validator.

On the other hand, a fixed stake is a staking mechanism where all the validators stake
an equal amount of $ANLOG tokens—the platform’s native asset—to participate in the
consensus process. Unlike typical proof-of-stake (PoS), where nodes must stake large
amounts of tokens to be considered for consensus, the PoT mechanism is fair. Any node
can participate as a validator provided it has staked a fixed amount of $ANLOG tokens
and accumulated a ranking score.

19
The PoT mechanism is a two-step process involving soft and hard voting at its core.
During the soft voting stage, a selected time elector (validator) proposes a block to be
included on the Timechain—the Analog’s event-based ledger. This process triggers the
hard voting phase, where a committee of 1,000 time nodes votes to determine whether
the transaction is valid or not. If more than two-thirds of the 1,000 time nodes attest to
the transactions, the block gets appended to the Timechain.

4.1 Fixed Stake

In many PoS-enabled Blockchains, the stake size determines whether a node gets
selected as a validator or not. In other words, the more coins a user stakes in the
network, the greater the chances of being chosen to validate the next block.

While this approach mitigates many of the problems inherent in PoW protocols (i.e.,
expensive computational resources and scalability limitations), it favors large token
holders. In the Analog’s case, all the time nodes stake an equal amount of $ANLOG
tokens to participate as time electors (block proposers) and time nodes (block
confirmers).

When combined with the ranking score, the fixed stake approach provides an equal
opportunity for all the time nodes to participate in validation and consensus. The fixed
stake mechanism is also crucial in bootstrapping the network because initially, there is
no ranking score computed yet for any time node.

4.2 Verifiable Delay Function

A VDF is a time delay imposed on the output of some pseudorandom generator. The
delay prevents malicious actors from influencing the output of the pseudorandom
generator because all the inputs get finalized before anyone can complete computing
the VDF.

20
The PoT consensus algorithm runs VDFs for periods called slots, which are periodically
computed after one epoch. An epoch is the time duration for which the network
randomly determines which nodes propose the blocks (time electors) and which ones
confirm the blocks (time nodes) in each time slot. Each epoch has 7,200 time slots.

During each epoch, the network releases a random seed that each node uses to compute
VDF based on its ranking score and the fixed stake. Whenever a node finds proof that it
qualifies to propose or confirm blocks, it broadcasts it and undertakes its responsibility
during its allocated slot, and broadcasts the result alongside VDF proofs. This way, the
network prevents malicious nodes from faking event data when proposing or
confirming blocks.

4.3 Participation Keys

Analog provides two distinct sets of keys:

● Spending keys. These are keys that enable a user to prove ownership of
$ANLOG tokens. Users can leverage their spending keys to stake the tokens on
the network and participate in decentralized governance.
● Participation keys. These are specialized keys located on a single node that
allows an online user to participate in the consensus process.

The primary goal of separating spending keys from participation keys is to ensure that
users’ spending keys do not get exposed when their accounts are validating event data
or participating in the consensus process. Any node that wants to validate event data or
participate in consensus on the Analog network can generate a participation key for a
particular account.

However, such a node can only validate event data or participate in consensus if its
private key authorizes the transaction, registering the account to go online with a
specific participation key. This way, the Analog network keeps the spending keys in
cold storage. For enhanced security, the Analog network automatically renews

21
individual participation keys after every 40,000 rounds of event data validation and
consensus.

4.4 Trust Index

The Analog network provides a natural defense against publishers that may attempt to
submit fake data or act in a byzantine manner using the trust index algorithm. The trust
index measures the subscribers’ trust in the event data that a given publisher or
tesseract submits to the network.

The entire Analog ecosystem is essentially a trust-based graph where nodes represent
subscribers and publishers while edges denote trust relations between them, as shown
below:

Figure 3: Graph notation for the Analog network

A trust relation from node A to node B shows how much trust B places in A. Thus, an
edge in the network has an associated trust value as its weight. When a publisher

22
onboards onto the Analog network, the protocol assigns it a trust index of 0. There are
two primary ways the network can derive the trust value:

● Direct interactions between tesseracts and subscribers. For example,

Decentraland users can use OpenSea’s submitted and validated event data to
create connected metaverses. This creates a trust relationship between a
Decentraland user (subscriber) and an OpenSea user (tesseract). Any time a
Decentraland user successfully uses OpenSea’s validated event data, the network
increments the trust index for a tesseract that is connected to the OpenSea.
● Referrals (trust propagation). By intuition, a good recommendation for a
subscriber, say X, is connected by many of X’s neighboring nodes. For example,
in figure 3 above, E has B and D as its neighbors. As such, B and D can
recommend E to use A’s submitted and validated event data. When this happens,
the network establishes a trust relation between A and E. Like the case with
direct interactions, the network increments A’s trust index anytime E successfully
uses A’s submitted and validated event data.

4.5 Ranking Score

Any time node can request to validate the submitted event data or confirm new blocks.
However, for the network to grant permission, such a time node must have a higher
ranking score, which is simply a numerical value that the algorithm assigns to each time
node. The network uses three parameters to arrive at a ranking score:

1. Node’s tenure on the Timechain. This indicates how other nodes in the
network perceive the time node in terms of its overall contributions to the
Timechain. The network uses crypto-economic concepts to assign this value,
such as rewards and penalties the node has generated on the network.

2. Node’s historical validation accuracy. This indicates the number of times the
time node has validated accurately. The more the correctly validated event
data, the higher the value for the node’s historical validation accuracy.

23
3. Average weighted value of ranking score for the vicinity nodes. Time nodes
do not carry the same weights when it comes to the ranking score. For
example, if time node A validates event data and other nodes, say B, C, and
D, find this data to be useful, then a special relationship forms between A, B,
C, and D. In other words, the ranking score associated with A increases on the
network. Suppose another time node, say X validates event data and only one
node, say Y finds that event data to be valuable. The ranking score associated
with X will also increase. However, A will have a higher weight than X
because it has more relationships. Therefore, when computing the final
ranking score for each time node, the network must factor in the connections
between the given node and the vicinity nodes.

4.6 PoT Workflow

Consensus via PoT is a two-stage process: block proposal and block confirmation.

4.6.1 Block Proposal

Time electors are a category of nodes that submit block proposals. The network rotates
the time electors at regular intervals, known as slots. Each time elector can only validate
event data during its allotted slot. The soft vote phase starts with publishers submitting
event data to the network. During this time, any time node that receives the
broadcasted event data forwards such data to the time elector.

The time elector collates the posted event data, verifies the publisher’s signature, and
generates the VDF proofs. It then gossips the hashed transaction alongside a VDF proof
to the rest of the time nodes in the network.

24
Figure 4: PoT soft voting process

4.6.2 Block Confirmation

At this stage, the network generates a new set of 1,000 time nodes via a VDF-based
lottery process to participate in the consensus process based on their staked coins and
ranking scores. Every time node again loops through its accounts to determine if it has
been selected to participate in the consensus process.

25
If selected, the time node determines whether the time elector is indeed a valid proposer
that the network selected to propose a new block. Each time node then checks for VDF
proofs, double-spending, overspending, and other problems with the proposed block. If
the proposed block is valid, the time node accepts it.

When all the 1,000 time nodes have voted to accept or reject the proposed block, the
network triggers an end to the confirmation round, triggering the tallying of the votes
function that works as follows:

● Each time node broadcasts its vote outcome alongside a VDF output to the other
nodes in the consensus committee via a gossip protocol in a P2P manner.
● When each time node receives the vote result, it computes its own VDF to
determine if the time node is indeed a valid member of the consensus committee.
● If the received vote output emanates from a valid member of the consensus
committee, it increments its vote tally by one. This process continues until each
time node has tallied all the votes from the other consensus committee members.
● If more than two-thirds of the time nodes vote to accept the proposed block, the
block gets appended to the Timechain, and all the nodes in the Analog network
get notified via a gossip protocol about the new Blockchain status. This
concludes the block confirmation process and triggers a new round of consensus.

26
Figure 5: PoT hard voting process

5.0 Security Architecture

According to Fischer-Lynch-Paterson (FLP) impossibility result, a deterministic

asynchronous decentralized consensus protocol can have at most two out of three
properties. The first is safety, where outputs must be valid and identical for all nodes.
The second is liveness, where nodes that do not fail should always generate a valid
result. The third is fault tolerance, where the system should survive even if one or more
nodes fail.

27
This section explores PoT’s safety and liveness properties, the circumstances under
which they can be compromised, and how the protocol prevents them from occurring.
Ultimately, we will also explore various practical complexities adversaries can use to
attack the platform.

5.1 Safety Guarantees

Unlike classical consensus protocols that usually leverage the longest chain principle,
such as PoW, the PoT mechanism adopts a probabilistic safety mechanism. Practically,
this probabilistic safety guarantee is as strong as conventional safety assurances. In the
PoT case, there are two stages in each consensus round: soft vote and hard vote.

During the soft vote, there is only one vote (from the time elector). However, this single
vote is accompanied by a hard vote where the process must collect more than
two-thirds of the votes for the consensus to take place. Since more than two-thirds of
1,000 time nodes are required for an agreement to occur, two different blocks cannot be
generated simultaneously.

This ensures that:

1. The network can never generate two or more blocks at the same height.
2. The network can never process an event data transaction from a block at height
(H+1) before executing all the transactions from the current height (H).
3. The network can never append the cross-chain event data to the Timechain
unless it has been signed by tesseracts and time nodes in a soft vote and hard
vote.

5.1.1 Safety Analysis

First, let us consider safety property number one. The PoT consensus is a two-stage
process involving a soft and hard vote. A single vote from the time elector must be
accompanied by a supermajority (two-thirds of 1,000 time nodes) for the decentralized

28
network to commit any block to the Timechain. In practice, no two blocks can be
committed to the Timechain simultaneously.

Next, let us consider safety property number two. The PoT algorithm has an inbuilt
𝑖𝑠𝑖𝑡𝑉𝑎𝑙𝑖𝑑 () function that determines whether a block is valid. This function guarantees
that even if adversarial nodes exceed one-third, no invalid block gets appended to the
Timechain. In other words, for a block at height (𝐻 + 1)to be considered valid, PoT
requires it to embed the current state of the block (𝐻).

Finally, let us consider the safety property (3). From (1) and (2), it follows that unless
more than two-thirds of the nodes are adversarial (which is highly unlikely due to
inbuilt incentive mechanisms), the network can never append the cross-chain event
data to the Timechain unless it has been signed by tesseracts and time nodes in a soft
vote and hard vote.

5.1.1.1 Safety Incentive Mechanisms

The PoT protocol ensures safety guarantees under the “less than a third” adversarial
conditions. However, due to safety property (2) outlined earlier, it is vital to know why
the “less than a third” adversarial condition holds.

The protocol requires both tesseracts and time nodes to lock a fixed number of tokens
(to be decided through a decentralized governance structure). The locked tokens are
registered with a smart contract. After the onboarding process, each tesseract and time
node must wait until the start of the next epoch before participating in the cross-chain
transfer process.

If any tesseract or time node decides to opt-out of the interoperability process, it has to
pause until the start of the next epoch to unlock its tokens. If a group of tesseracts
decides to collude in a TSS process and fetches an erroneous event data that time nodes
do not approve, their staked tokens are automatically slashed.

29
5.2 Liveness Guarantees
The liveness property in consensus protocols is a situation where honest nodes always
generate valid output. For example, a consensus protocol that allows nodes to get stuck
in endless loops can never recover from a disagreement which means that such an
algorithm cannot support liveness.

The liveness property of the protocol is guaranteed so long as “greater than or equal to a
third” of the time nodes are ever offline. No epoch should ever comprise more than a
third of time nodes that cannot communicate with the rest of the decentralized nodes.
With regard to liveness, PoT ensures that:

1. Time nodes will eventually append a block to the Timechain at every height.
2. Time nodes will eventually process every transaction for any appended block.

5.2.1 Liveness Analysis

Let us start the analysis by considering the liveness property (1). As is the case with
safety property (1), this property assumes that any block committed to the Timechain
must undergo two stages: soft vote and hard vote. If more than two-thirds of the time
nodes are online, the event data will eventually be appended to the Timechain.

Now let us examine the liveness property (2). Again, as is the case with safety property
(3), the nodes can always generate the block so long as more than two-thirds of them are
online. This essentially means that executing the transaction will progress under the
“less than a third time nodes” condition.

5.2.1.1 Liveness Incentives

The liveness property requires the time nodes to contribute non-zero cost resources
($ANLOG tokens) to participate in the consensus process. Similarly, this would also
require an incentivization mechanism that exceeds non-zero costs to reward honest
block proposers and confirmers.

30
To this end, time nodes that want to participate in the validation consensus process
must lock a fixed amount of $ANLOG tokens in a smart contract to be selected. Before
an interoperable execution takes place, consensus must occur on the network. Time
electors and time nodes that successfully validate and confirm blocks to the Timechain
receive $ANLOG tokens as rewards and have their ranking scores automatically
increased.

5.3 Attack Vectors

This section explores the two most common rational attacks in decentralized networks:
Sybil and bribery attacks. It also examines how PoT protocol prevents these attacks
from occurring in the wake of increased adversaries. In the subsequent section, we
extend the discussion to incorporate irrational attacks.

5.3.1 Sybil Attacks

A Sybil attack is a security threat in Blockchains where a user attempts to take over the
network by generating multiple accounts and nodes. Sybil attackers may out-vote the
honest nodes in a decentralized network if they generate enough fake identities.
Typically, such attackers can decline to collate or broadcast the transactions, effectively
blocking other nodes from undertaking their functions.

In Analog, a Sybil attacker must control more than a third of the time nodes in a
particular slot to corrupt the communication. This is highly unlikely because an attacker
will need to lock more $ANLOG tokens in its wallet to launch the attack. If honest
nodes in the network detect this kind of attack, the attacker would be severely punished
by a slashing mechanism.

5.3.2 Bribery Attacks

This is an attack where an adversary attempts to corrupt the network by coordinating

with more than a third of the nodes through bribery. If the attacker succeeds in bribing
more than a third of the nodes, they can steal all the locked assets on the source chain.

31
Doing so results in the asset being minted on the target chain without a respective burn
event on the source chain.

In a PoT-enabled chain such as the Analog network, the attacker has to pay at least a
third of the time nodes. This is not profitable, provided the sum value of all staked
$ANLOG tokens for all the malicious nodes is greater than three times the value of
tokens in the source chain. Analog enforces this constraint through a dynamic
decentralized governance mechanism that adjusts the minting, burning, and transaction
fees.

6.0 Zero-Knowledge Proofs

The Analog network utilizes the zero-knowledge scalable transparent arguments of
knowledge (zk-STARKs). zk-STARKs are a variation of ZKPs that generate proofs of the
form 𝑓(𝑥) = 𝑦 where f is a public function that takes an arbitrarily long time to
compute. Still, the proof can be verified quickly and scales exponentially faster than the
data size.

Unlike zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK)

that requires a trusted setup, a zk-STARK is trustless. It uses publicly verifiable
randomness with no trusted setups to generate verifiable computation systems. Given
that there are no trusted parties in the setup phase and publicly verifiable randomness
is used instead, a zk-STARK-based system eliminates the single point of failure (SPOF)
associated with parameter setup generation procedures in zk-SNARKs.

In addition, zk-STARKs do not rely on expensive cryptographic techniques like elliptic

curves, pairings, and knowledge-of-exponent assumptions like the ones that
zk-SNARKs use. Instead, zk-STARKs rely on collision-resistant hash functions and
information theory that gives them solid arguments for post-quantum security.

32
6.1 zk-STARKs Workflow

We are building the Analog network to preserve privacy when users interact with their
$ANLOG tokens (the protocol’s native asset) by leveraging zk-STARKs primitives on
the generalized compute layer. As a hybrid privacy-preserving platform, the network
allows users the flexibility to either leave their transactions as transparent or private
data on the Timechain. The two requirements for such a hybrid privacy-preserving
mechanism include:

● Only whitelisted publishers/tesseracts (nodes that wish to transact privately) are

allowed to leverage the zk-STARKs protocol. As such, each publisher/tesseract
has two keys: a transparent key for transmitting public event data and a stealth
key for submitting private transactions.
● The subscriber must explicitly approve incoming private transactions via a
stealth address.

The general workflow of such a process is as follows:

1. Publishers accumulate multiple event data transactions while in off-chain mode

and submit them to a zk-STARKs protocol in the form of CI statements.
2. The zk-STARK prover generates one proof. This phase involves two steps. The
first step is computing the completeness statement, while the second step
generates algebraic intermediate representation (AIR) and an associated FRI.
3. The zk-STARK verifier verifies the proof and updates the state.

Figure 4 illustrates these steps.

33
Figure 4: High-level overview of the zk-STARKs workflow

6.2 zk-STARKs Use Cases

There are two primary use cases of zk-STARKs on the Analog network:

● Enhancing privacy. Analog is a privacy-protecting chain built based on

zk-STARKs’ solid primitives. With Analog, publishers/tesseracts and subscribers
leverage stealth addresses to interact efficiently and privately. The address owner
can also choose to disclose its address by leveraging transparent keys. In this
regard, a transparent-to-transparent key-based transaction works similarly to
public and permissionless chains where transactions are publicly visible on the
Timechain. The two address types are also interoperable. For example, a
transaction can occur between stealth addresses and transparent addresses and
vice versa.
● Enhancing scalability. With Analog’s zk-STARKs, dApps such as DEX
aggregators can allow users to compute off-chain-based transaction proofs and

34
only submit those transactions to on-chain networks when gas fees are
reasonable enough to pay for needed liquidity.

7.0 Gateway Smart Contracts (Continuum)

Gateway smart contracts enable the Analog network to transfer messages across all the
connected blockchains. For each blockchain onboarded onto the Analog network, a
gateway smart contract—managed jointly by tesseracts via one public key and multiple
partial private keys—is deployed to that chain.

Tesseracts use the gateway smart contract to pass messages between interconnected
chains. For any cross-chain message to be transacted across the Analog gateway, it has
to be signed by more than 90% of the tesseracts on that network. Each tesseract in the
interoperability process must stake an equal amount of $ANLOG tokens and holds
exactly one partial key share.

The Analog gateway API can execute transactions on the external network under two
conditions:

● The cross-chain message has been validated by tesseracts on the source chain.
More than 90% of tesseracts on the source chain have to attest to the transaction
by partially signing it in a TSS process.
● The cross-chain event data has been confirmed and appended to the Timechain.
The cross-message has to undergo two PoT processes on the Analog network:
soft vote, where the time elector proposes the transaction, and hard vote, where
more than two-thirds of the time nodes confirm it.

8.0 Event Data Marketplace

The event data marketplace is a decentralized storefront for validated event data.
Unlike the hub (centralized) model, where a centralized party organizes data and

35
defines interaction rules, Analog’s event data marketplace is completely decentralized
where nodes exchange validated event data in a trustless, peer-to-peer (P2P) manner.

Data providers and subscribers can interact and transact with the marketplace via
decentralized consensus rules (PoT) and smart contracts. This prevents monopolistic
behaviors that are inherent in centralized data marketplaces, allowing community
members to access accurate and verifiable event data in a democratic manner.

Our infrastructure for the marketplace relies on a technology stack that incentivizes
users to submit accurate event data and communicate with global nodes in a P2P
fashion. The Analog network provides a robust, low-latency, and secure event data
delivery and persistence, and at scale, powering the next generation of dApps.

The marketplace has three main stakeholders:

1. Publishers (data providers). These are individuals or companies that supply

event data to Analog’s event data marketplace. The network employs the trust
index score— which measures the subscribers’ trust in the publisher—to ensure
that publishers submit valid event data. The network also uses incentivization
mechanisms where publishers have their trust indices automatically increased as
they receive direct payments from subscribers.
2. Time nodes (validators). These are entities that propose and confirm blocks via
the PoT consensus protocol to the marketplace. The network rewards time nodes
with $ANLOG tokens for their efforts.
3. Subscribers. These are entities that are interested in buying the event data for
their off-chain and on-chain dApps. They can then use the validated event data
to trigger smart contracts in the Analog ecosystem as shown below:

36
Figure 5: Event Data Marketplace

Fair exchange of event data, even between two parties, is impossible without a trusted
third party. In our case, the trusted third party is the Analog network which enforces
engagement rules between publishers and subscribers.

As a public, trustless entity, the Analog network consists of immutable, validated

transactions that ascertain the source and ownership of the event data being exchanged.
However, privacy is a major concern in public chains like Bitcoin and Ethereum because
anyone can link random-looking addresses to their real owners.

Even though the Analog network is a public chain, we want to ensure that the event
data being traded on the platform does not leak to any other party except the publisher
and the consumer. In this regard, the Analog network leverages zk-STARKs to secure
the following:

● Privacy of the specification. The source code of the smart contract should
not be made public during the deployment and subsequent processes of
execution and synchronization.
● Privacy of the state. The internal state of the smart contract can contain
sensitive users’ secrets that need to be protected.

37
● Privacy of the execution process. Once the network invokes the smart
contract, the client’s executing process, including the call arguments and
returns values, should remain hidden from the public view.

8.1 Timegraph API

Businesses are increasingly providing various services over web application

programming interfaces (APIs), ranging from offering asset price data to executing
traditional transactions. We are also witnessing the same phenomenon with dApps that
interact with off-chain data.

Yet, existing APIs are not natively compatible with dApps. They are centralized, costly,
and insecure due to their reliance on intermediaries. In the recent past, we have seen
decentralized oracle network (DON) solutions emerging to facilitate interaction
between dApps and off-chain data.

However, these networks still employ third-party oracles because they cannot operate
their own oracle nodes. Such DONs are costly and create an additional attack surface.
Timegraph API eliminates third parties to meet the strict decentralization and security
requirements of web 3.0 APIs.

It is a secure and cost-efficient solution that provides a conventional API service to

smart contracts in a fully decentralized manner. The Timegraph API is the
third-generation-based, Blockchain-native solution that allows businesses and
developers to build, monetize, and manage multiple dApps from different chains at
scale. The Timegraph API has three basic features:

● It is a cross-chain interface. Multiple off-chain dApps can seamlessly

interact with Analog’s validated event data in a decentralized way.
● It is a decentralized network of first-party oracles. It allows businesses to
serve as first-party oracles and access verified event data in a
decentralized manner.

38
● It is a privacy-preserving mechanism for sharing verified event data.
The Timegraph API enforces zk-STARKs within its smart contracts to
allow multiple dApps to access verified event data privately.

To achieve the aforementioned elements, the Analog network provides incentivization

mechanisms where parties, i.e., publishers, subscribers, and time nodes, are reconciled
through the governance and security structures of $ANLOG token as shown below.

We have conceived the Analog Timegraph API as a decentralized network of first-party

oracles to allow individuals and businesses (publishers) to submit event data to the
platform in a fully decentralized and Blockchain-native manner. The decentralized
governance structure inherent within the API’s infrastructure allows stakeholders to
build, manage, and monetize time-based dApps at scale.

The time-dependent dApps use the $ANLOG tokens to gain access to the Timegraph
API. $ANLOG token holders (publishers and subscribers) can stake their coins and
participate in governance in a decentralized manner.

39
Figure 6: Features of the Event Data Marketplace

To facilitate the cross-chain transfer of validated event data from the marketplace to
off-chain dApps and vice versa, the Analog network uses Tesseracts. A Tesseract is
essentially a node that connects the Analog network and off-chain dApps, allowing for
the cross-chain transfer of verified event data.

With businesses operating their own oracles on the Analog network, it means they
would be signing their event data submissions with their private keys. This guarantees
that the event data has not been tampered with. Moreover, first-party oracles are private
by default, which, when combined with zk-STARKs, prevents third parties from
observing raw data that the network is processing.

40
8.2 Use Cases
Analog network empowers dApp developers and Blockchain ecosystems to unlock the
cross-chain transfer of value. Due to its decentralized design and an open Timegraph
API, businesses can use it for various use cases, such as:

8.2.1 Decentralized Finance

The past few years have demonstrated that decentralized finance (DeFi) can potentially
unlock many possibilities that were previously closed to consumers. To date, the total
value locked (TVL) has grown ten times from May 2020 to date, according to DeFi
Pulse. However, despite this phenomenal growth, the industry requires interoperability
solutions to allow liquidity to move freely and securely from one protocol to another.

Today’s leading DeFi dApps can only operate on one specific chain, which isolates the
applications from the majority of liquidity in the cryptocurrency space offered on other
networks. Below are some notable DeFi use cases that the Analog network will power:

9.2.1.1 Decentralized Money Markets

While money markets have evolved, their design and goals have largely remained the
same. Borrowers use such markets to take a short-term loan to borrow one currency, say
US dollars, while using another asset, say Euros, as collateral. This collateral serves as a
guarantor that the borrower will pay back the debts in a given time frame.

With the rise of DeFi ecosystems, many decentralized money markets (DMMs) such as
CREAM and Aave have emerged to allow users to borrow and lend their on-chain
assets in a trustless manner. Instead of operating as centralized entities, DMMs
primarily function based on smart contracts managed by decentralized nodes.

To ensure that DMMs do not become insolvent and stay overcollateralized, they require
real-time connection to other Blockchain ecosystems. Since there is no native

41
interoperable solution, smart contracts in one chain, say Aave, cannot communicate
event data to another platform such as CREAM.

The Analog network can facilitate a cross-chain connection between the two platforms
in near real-time. For example, the platform can help lenders in Aave determine when
borrowers in the CREAM protocol should have their positions liquidated in different
chains.

8.2.1.2 Decentralized Exchanges

Decentralized exchanges (DEXs) differ from centralized exchanges (CEXs) because they
allow traders to remain in control of their funds via a decentralized network. DEXs
allow users to solve security, transparency, and efficiency challenges that CEXs lack.
However, despite these advantages, most DEXs are not fully decentralized.

In most DEXs, servers (centralized entities still host order books, and users do not hold
their private keys. The Analog network can allow users to create multi-chain order book
DEXs where bids are partially filled trustlessly across different networks of liquidity
pools (LPs). This infrastructure solves the problem of liquidity fragmentation without
any centralized bridges or wrapped assets.

8.2.1.3 Stablecoins

Stablecoins are crucial components DeFi that allow users to represent fiat currencies
such as the U.S. dollar or the Euro on the Blockchain as digital tokens. Stablecoins
promote relative stability in an often-volatile cryptocurrency market by maintaining a
1:1 peg with fiat currencies through various mechanisms. These solutions include
decentralized stablecoins, fiat-backed coins, and algorithmic stablecoins.

For example, algorithmic stablecoins usually maintain their peg through

crypto-economic structures. Take the case of Fei protocol, for example. The protocol

42
essentially functions as a centralized algorithmic entity where open markets uphold the
peg through reweighting.

Analog can help Fei users to scale up reweighting process on open markets. For
example, users can mint FEI with an equivalent deposit value of ETH, which gets added
to the system’s reserve to serve as a protocol-controlled value (PCV). If FEI trades below
the peg, Analog smart contracts can trigger the PCV to buy the coin on the open market,
such as Solana. Likewise, if FEI is trading above the peg, Analog smart contracts can
mint more coins and sell them on the open markets.

8.2.1.4 Yield Markets

DeFi-based yield farming allows the cryptocurrency community to earn rewards with
their assets whenever they stake or lend them on Blockchain platforms. Besides
obtaining new tokens when the price of an asset increases, users can also receive other
incentives. Presently, most yield farming protocols are Ethereum-based, which means
users can only operate in a siloed liquidity environment.

Besides a fragmented liquidity framework, most protocols have weak assumptions

about event data, which is crucial in today’s highly competitive and fast-paced
environments. For example, market makers cannot easily determine whether they
should lock up their cash in liquidity pools to maximize their annual percentage rates
(APRs) or annual percentage yield (APYs).

The Analog network can help such users determine the appropriate time to lock up
their funds for maximum return on investment (ROI). For example, the Analog network
can capture the correct signals on Aave and feed the signal to yEarn, allowing such to
determine the appropriate time to invest on the platform.

43
8.2.2 Metaverse

The metaverse is no longer what it used to be, as depicted some years back. It has
evolved into a disruptive ecosystem, providing new opportunities for gamers, artists,
and creators by not just reimagining the entire digital assets economy but inventing it
afresh. As a primary go-to platform for entertainment, workplace, and even
e-commerce, metaverse not only extends the web but is also its successor.

However, before Blockchain-enabled metaverses become a reality, the issue of

interoperability has to be resolved. Some users believe that the metaverse sector needs
require a single operator to address the interoperability issue. However, at Analog, we
believe that the metaverse would require multiple chains and communities, with each
network implementing its own technology stack.

Our mission is to allow diverse communities on these chains to seamlessly transfer their
assets from one network to another while helping developers to build cross-chain
solutions in the sector. Our interoperability framework addresses three main use cases:

9.2.2.1 Off-chain to the on-chain transfer of metaverse assets

Presently, gaming assets such as weapons and avatars created in one virtual world
cannot be seamlessly moved over to an on-chain platform. For example, while gamers
can easily buy hundreds of dollars of cosmetics in Fortnite, they cannot move such
purchases to another gaming ecosystem when they opt out of the game.

Analog can allow such gamers to transfer such off-chain purchases to on-chain
networks easily. For example, a user can purchase the Jinx skin in Fortnite and transfer
them to the Sandbox or Decentraland.

8.2.2.2 On-chain transfer of NFTs from one game to another

Virtually all metaverse platforms allow gamers to create, explore and interact with
various games in their ecosystems while earning non-fungible tokens (NFTs) as
rewards. However, users cannot transfer such NFTs to other games within the same

44
chain. For example, users cannot transfer an NFT from WonderQuest to Ethermon and
vice versa despite the games existing within the same Decentraland environment.

With Analog, users can seamlessly transfer NFTs from one game to another on the same
chain. For example, when users get rewarded with an NFT in WonderQuest and
Ethereum confirms the transaction, they can instantly use the asset in another game
such as Ethermon.

8.2.2.3 Cross-chain transfer of NFTs

Because of the many siloed chains, event data cannot move between them. For example,
when a user concludes a task in Decentraland and gets a badge or an avatar, they
cannot exchange that asset in another platform such as Axie Infinity or the Sandbox.
With Analog, users can easily integrate multiple virtual worlds via a decentralized
Timegraph.

For example, a player can be rewarded in Decentraland, and Axie Infinity confirms the
transaction. This way, the player uses the reward in an Axie Infinity.

45
9.0 Analog Economics Overview

We have conceived Analog’s tokenomics system as a healthy, long-term, self-sustaining

platform with participant incentives aligned towards achieving complete
decentralization and security. The contributions of publishers, subscribers, and time
nodes—the main participants in the Analog ecosystem—are discussed below.

9.1 Tokenomics Actors

The Analog’s tokenomics ecosystem has three main actors:

9.1.1 Publishers

Publishers are the lifeblood of the Analog ecosystem and, as such, will be rewarded and
incentivized for submitting quality event data. First and foremost, publishers will be
paid directly when subscribers consume their submitted event data. The payments
received from subscribers (minus transaction fees) will be sent directly to the
publisher’s wallet.

Besides direct payments, the network will also incentivize publishers who submit
quality event data. This will be subject to governance structures. For example, the
network may pay 10% of accumulated transaction fees to publishers who do not drop
below a certain trust index threshold, say 0.8, after every four weeks.

The network can scale down these reward shares based on their trust index score until
they receive no reward after, say 0.5. This ensures that the most reliable publishers are
rewarded more. Publishers can also receive bonuses if subscribers pay extra costs to
increase the priority of the event data transaction.

46
9.1.2 Subscribers

The event data marketplace is a meeting place for subscribers and publishers.
Subscribers find value in the validated event data offered when they use it as an input
for their time-dependent dApps, smart contracts, or traditional applications. Because of
the value generated from event data, subscribers will be required to pay for services
rendered.

The delivery of event data on the network follows the broadcast/validate/subscribe

paradigm. When publishers submit event data, time nodes validate it in near real-time,
allowing subscribers to promptly use them for various purposes. $ANLOG, the
network’s native coin, will enable subscribers to subscribe to validated event data.

9.1.3 Time Nodes

We want to encourage as many stakeholders as possible to participate in the Analog

network as time nodes. With more time nodes, the network can fairly select which
nodes—whether block proposers or confirmers—participate in the validation and
consensus processes. This way, the network achieves complete decentralization and
security.

The entire PoT ecosystem is a collective rewards scheme where the more the users join
as time nodes, the more $ANLOG tokens everyone receives. The mathematics for time
nodes’ return on investment (ROI) is:

ROI = Time Node Incentives + Network Fees – Costs required to run a time node 

Where:

● Node incentives. These are the protocol-based rewards— denominated in

$ANLOG tokens—that the platform assigns for every newly confirmed block.
The network will generate these rewards from inflationary issuances under a
well-defined inflation schedule. We believe that protocol-based rewards will

47
drive the majority of time node incentives in the early days of the network if the
system adheres to a predefined issuance schedule.
● Network fees. Network fees provide two primary benefits in Analog’s
tokenomics design: compensating time nodes for their computational resources
in confirming blocks and reducing network spam. Each transaction that goes
through the Analog network will incur a network fee (to be defined under a
governance structure) so long as it has been confirmed on the Timechain.
● Overheads. These are costs required to run the time node, such as bandwidth
and electrical and hardware expenses. Because PoT does not require
computationally-intensive resources, this figure is minimal, which means more
returns.

9.2 Token Specifications

The Analog network is powered by $ANLOG tokens. The network uses the $ANLOG
token to incentivize positive actions by nodes and subscribers while penalizing
deceptive entities on the platform. We have minted $ANLOG tokens as ERC-20/BEP-20.

However, once the mainnet goes live, we will re-mint the tokens again and provide an
interface that allows existing token holders to transition to the new tokenomics system.
Table 1 summarizes the token specifications:

Table 1: $ANLOG specifications

Feature Specification
Token standard ERC-20/BSC
Token name ANALOG
Token Ticker $ANLOG
Total token supply 90,579,710 $ANLOG
Total vesting period None
Mintable? Yes
Burnable Yes
Pre-minted Yes

48
9.3 Staking

The network will reserve 10% of the total $ANLOG token supply to provide staking
services. We expect staking services to secure the platform and encourage honest
behaviors by nodes. To validate event data, participants will be required to stake their
$ANLOG tokens.

The network will, in turn, compensate such validators for their services depending on
the amount of $ANLOG tokens staked and the staking duration. We will choose a
compensation function that minimizes variance, ensuring that those participants who
stake disproportionally large amounts of $ANLOG tokens do not disenfranchise other
stakers.

The network will also discourage the formation of staking pools, providing a truly
decentralized platform. Besides incentivizing time nodes to validate event data,
$ANLOG tokens will also enable token holders to participate in Analog’s on-chain
decentralized governance model (described in the subsequent sections).

9.4 Token Distribution

At the genesis of the Analog network, 90.58 million $ANLOG was minted. This
represents the fixed and immutable maximum supply of $ANLOG tokens. Table 2
highlights the distribution schedule mechanism:

49
Table 2: Distribution framework

Stakeholder Allocation Percentage Vesting

Team and advisors 17,210,144.90 19.00 4 years

Treasury 13,224,637.66 14.60 Ongoing

Private sale 24,275,362.28 26.80 2 years

Community 34,420,289.80 38.00 Ongoing

allocations

Public sale 1,449,275.36 1.60 Ongoing

Total 90,579,710.00 100

50
Figure 7: Token distribution framework

Below is a summary of how the network will distribute $ANLOG tokens:

● Public sale. It includes all the $ANLOG tokens offered during pre-launch sale or
lock drop allocations open to public participation.

● Community allocations. This includes the ecosystem funds, staking rewards, or

airdrops that will eventually go to the Analog community

● Insiders. The $ANLOG tokens offered to insiders will comprise the Analog team,
advisors/partners, and venture capitalists (VC).

● Treasury. The primary objective of the treasury is to create the needed runway as
opportunities arise. We have slated this for realizing partnerships, developer
rewards, community grants, operating capital, exchange listings, strategic
investments, and any investment that will ensure long-term benefits of the
project.

9.5 Governance

Decentralization is an underlying premise that ignited the creation of Blockchain. At

Analog, we believe that $ANLOG token holders are the ultimate decision-makers on
matters such as determining the block size, reward scheme, voting, and other decisions.
That is why our model of governance hinges on self-evolving expressive representation.

The network will allow $ANLOG token holders to vote directly or delegate their voting
power to other representatives. The primary goal of the Analog is to ensure that the
majority's decisions command the network. The network uses an on-chain smart
contract that enforces voting mechanisms like referendum and batch approval voting to
achieve this goal.

51
9.5.1 Participants in Analog Governance

The $ANLOG token is at the heart of Analog’s decentralized governance structure. It

allows direct and low-friction interaction set forth by the community. Token holders use
$ANLOG tokens as the basis for voting on submitted proposals and can increase their
voting power (weight) by locking up their tokens for an extended time.

Token holders can use their $ANLOG tokens to:

● Propose a referendum
● Prioritize a referendum
● Vote on an active referendum

9.5.2 Process

To make any changes to the network, the protocol assembles active $ANLOG token
holders to administrate the decision. The proposal must go through a referendum to
allow all the token holders to decide.

9.5.3 Referendum

A referendum is a simple, all-encompassing, stake-based voting scheme in the Analog

network. Any node with sufficient $ANLOG tokens can submit a proposal to be voted
on in the network. Each referendum comprises a specific proposal with a fixed period
for voting.

As an on-chain governance model, Analog’s decentralized governance smart contract

encapsulates each proposal in the form of a privileged function call in the Timechain
Virtual Machine (TVM) or runtime.

The function call automatically triggers an election process and can even switch out the
entire TVM’s code, potentially achieving what would otherwise need a hard fork. Token

52
holders can either vote “yes” to approve the proposal, “no” to reject the proposal, or
even abstain entirely.

When the voting process completes, the network undertakes a vote tally to determine
whether the proposal has been approved or not. Each referendum has an enactment
delay that starts immediately after the referendum ends and when the changes get
enacted (assuming the proposal is approved).

Since the project is still work-in-progress, this time is not yet voted on by the
decentralized community. We will communicate when this happens. However, we also
believe that emergency proposals that deal with significant issues with the protocol
need to be fast-tracked, requiring a shorter time to implement. We will also
communicate this time when the community decides.

1. Proposing a referendum

Anyone can initiate a proposal to alter the network rules by locking up a minimum of
200 $ANLOG tokens for 7 days. If another token holder agrees with the proposal, they
also lock up the same number of tokens for 7 days to support, i.e., they endorse the
proposal. The proposal that receives the highest bonded support (highest staked
$ANLOG tokens) gets selected as a referendum issue in the next voting cycle.

To illustrate further, consider the following case.

Alice and Bob initiate proposals A and B respectively on the network. Proposal A
garners the following support:

● George stakes 20 $ANLOG

● Sam stakes 40 $ANLOG

In this case, Alice receives two endorsements with 60 $ANLOG in staked coins.
Suppose Bob’s proposal (B) receives three endorsements as follows:

53
● Sara stakes 20 $ANLOG
● Jane stakes 20 $ANLOG
● Faith stakes 10 $ ANLOG

In this case, Bob’s proposal has garnered three endorsements with a total of 50
$ANLOG. On account of this, Alice’s proposal—with 60 $ANLOG in staked coins
compared to Bob’s 50 $ANLOG—gets selected as a referendum issue despite having
only two endorsements.

2. Voting timetable

A new referendum issue will come up for a vote every four weeks, assuming at least
one proposal is in the queue. However, for an emergency referendum, the issue will
come up immediately after a token holder secures 1,000 $ANLOG in bonded tokens.
The network determines the top proposal by the amount of staked (bonded) coins
behind it. Analog network will also support multiple referendum agendas, excluding
emergency referenda.

Voting on the referendum agenda

A voter must lock their $ANLOG coins for at least one day (24 hours) to vote for a
referendum agenda in a voluntary lock-up scheme (described in the next section). This
ensures the network achieves minimal economic buy-in to the desired election results
and avoids vote selling.

A voter has three choices when it comes to voting on a referendum agenda:

● Vote “Yes” to approve the referendum agenda

● Vote “No” to disapprove the referendum agenda
● Entirely abstain from voting

When voting, the voter must specify the number of $ANLOG tokens that get locked up
and the lock-up time.

54
Tallying

At the end of the election process, the network tallies the votes cast using a weighted
approach that takes into account two elements:

● The number of approvals, i.e., the weighted number of votes for token holders
that voted “Yes.”
● The number of disapprovals, i.e., the weighted number of votes for token holders
that voted “No.”

A referendum agenda can only pass if a supermajority of token holders (weighted

votes) vote for it. In other words, the number of approvals is greater than the number of
disapprovals. For example, suppose token holders vote as follows in a referendum
agenda:

● Sara votes “Yes” by locking 20 $ANLOG for 10 days

● Jane votes “No” by locking 20 $ANLOG for 50 days
● Sam votes “Yes” by locking 10 $ ANLOG for 4 days

The Analog network will tally the votes as follows:

Token Locked Lock-up Lock-up Computation Votes

holder $ANLOG Time Multiplier
tokens (days)
Yes No

Sarah 20 10 2 20*2 40

Jane 20 50 4 20*4 80

Sam 10 4 1 10*1 10

55
Total votes cast 50 80

As seen from the computations above, “Yes” has 50 votes while “No” has 80 votes
which means the referendum agenda is rejected.

9.5.4 Voluntary Locking of Tokens

We will utilize the notion of “voluntary locking,” where token holders voluntarily lock
up $ANLOG tokens for an appropriate time to increase their voting power. The network
will use voluntary locking as a basis for computing the number of votes that each token
holder (voter) contributes in an election process.

The formula below illustrates this process:

𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑣𝑜𝑡𝑒𝑠 𝑐𝑜𝑛𝑡𝑟𝑖𝑏𝑢𝑡𝑒𝑑 𝑏𝑦 𝑒𝑎𝑐ℎ 𝑣𝑜𝑡𝑒𝑟 = 𝑆𝑡𝑎𝑘𝑒𝑑 $𝐴𝑁𝐿𝑂𝐺 𝑡𝑜𝑘𝑒𝑛𝑠 * 𝐿𝑜𝑐𝑘 − 𝑢𝑝 𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑒𝑟.

Each time the number of lock-up period doubles, the lock-up multiplier increases by
one, as shown below:

Lock-up Time (Days) Lock-up Multiplier

1 0.1
8 1
16 2
32 3
64 4
128 5
256 6

The network has set 6 (equivalent to 256 days) as the maximum number lock-up
multiplier. Token holders can increase their voting power by locking up more $ANLOG
tokens for extended periods. For example, if you lock up 30 $ANLOG tokens for 28
days (with a lock-up multiplier of 3), your computed votes become 30 * 3=90 votes.

56
On the other hand, if you lock up 10 $ANLOG tokens for 10 days, your computed votes
become 10 * 2=20 votes. It is worth noting that locking up $ANLOG tokens only
prohibits the token holder from transferring tokens to another account. They can still
use locked-up tokens to stake on the network.

By locking up $ANLOG tokens, the network dissuades vote-selling and achieves

minimal economic buy-in during an election process. Because of the time-locking
mechanism offered by this model, token holders with fewer $ANLOG tokens can also
influence the referendum result.

10.0 Tentative Roadmap

The platform and $ANLOG token rollout will occur in phases, with a preliminary
roadmap as set out below:

57
58
11.0 Community
To bring the project to life, we are building a community of individuals and businesses.
This community development will be driven via actively managed Discord and
Telegram groups, incentivizing community managers with $ANLOG from the Analog
One Foundation.

We are actively seeking theoretical physicists, mathematicians, actuaries, and computer

scientists to join us in helping to optimize how the $ANLOG token works and its
incentive rewards economics.

Learn more about the project and community at the Analog website.

59
12.0 Our Team
We are a globally dispersed team of experts in physics, cryptography, computer science,
economics, and fintech systems. In today’s market, it appears that many token offerings
come to market with little or no governance implemented.

In response to this, a steering committee will be initiated with members from the
advisory board. All members of the steering committee will have specific roles aligned
with specific business issues and a general responsibility to ensure that the project
proceeds in line with our defined roadmap.

60
Legal Disclaimer
$ANLOG Token is designed to be a utility token that functions as the unit of payment and
settlement between participants who interact within the Analog ecosystem. $ANLOG Token
does not in any way represent any shareholding, participation, right, title, or interest in the
Governing body, the Issuer, its affiliates, or any other company, enterprise, or undertaking, nor
will $ANLOG Token entitle token holders to any promise of fees, dividends, revenue, profits or
investment returns, and are not intended to constitute securities in the United States or any
relevant jurisdiction. The ownership of $ANLOG Token carries no express or implied rights
other than that which may be afforded by Analog and/or any other third parties who may use
such Tokens.

61