PreprintPDF Available

Practical Web3 Solution Considerations

Preprints and early-stage research may not have been peer reviewed yet.


This monograph gives business, strategy, and technical professionals a practical and technology neutral introduction to decentralized web3 solutions and a framework for methodical consideration of their own smart contract- and blockchain-enabled solution concepts. Decentralization, Blockchain, Smart Contracts, Oracles and cryptographic Tokens are considered. Actor roles in a Decentralized Solution Ecosystem are presented, as well as the Trust and the Solution Trustworthiness required for those actors to willingly engage in the Decentralized Solution Ecosystem. Token Economics of decentralized web3 solutions and a template for Kickstarting a Use Case are offered. Leadership and Governance of a decentralized solution is reviewed, along with Boundary Resources that enable effective value exchange by Decentralized Solution Ecosystem actors and Indicators to manage risk and drive continuous improvement of the solution. Regulatory and Compliance Considerations and Decentralized Autonomous Organizations are discussed. A process for methodical consideration of Your Web3 Solution concept is offered. Monograph concludes with consideration of Web3 as a wave of Schumpeterian Creative Destruction.
Practical Web3 Solution Considerations
Page 1
Practical Web3 Solution
by Eric Bauer
This monograph gives business, strategy, and technical professionals a practical and technology-
neutral introduction to decentralized web3 solutions and a framework for methodical consideration
of their own smart contract- and blockchain-enabled solution concepts. Decentralization,
Blockchain, Smart Contracts, Oracles and cryptographic Tokens are considered. Actor roles in a
Decentralized Solution Ecosystem are presented, as well as the Trust and the Solution
Trustworthiness required for those actors to willingly engage in the Decentralized Solution
Ecosystem. Token Economics of decentralized web3 solutions and a template for Kickstarting a Use
Case are offered. Leadership and Governance of a decentralized solution is reviewed, along with
Boundary Resources that enable effective value exchange by Decentralized Solution Ecosystem
actors and Indicators to manage risk and drive continuous improvement of the solution. Regulatory
and Compliance Considerations and Decentralized Autonomous Organizations are discussed. A
process for methodical consideration of Your Web3 Solution concept is offered. Monograph
concludes with consideration of Web3 as a wave of Schumpeterian Creative Destruction.
Keywords: web3, web 3.0, web3 solution, blockchain, smart contract, oracle, tokenization, trust,
solution trustworthiness, decentralization, decentralized ecosystem, token economics, boundary
resources, governance, leadership, decentralized autonomous organization, DAO, quality indicators,
creative destruction
Practical Web3 Solution Considerations
Page 2
Title Page
1 Introduction 3
2 Decentralization 10
3 Blockchain 24
4 Smart Contracts 29
6 Tokens 43
7 Decentralized Solution Ecosystem 49
8 Token Economics 56
9 Kickstarting a Use Case 65
10 Leadership 78
11 Governance 88
12 Trust 94
13 Solution Trustworthiness 104
14 Boundary Resources 118
15 Indicators 129
16 Regulatory and Compliance Considerations 143
17 Decentralized Autonomous Organizations 148
18 Your Web3 Solution 154
19 Creative Destruction 162
20 Acknowledgements 173
21 References 174
© 2023 Nokia
Practical Web3 Solution Considerations
Page 3
1 Introduction
This document gives business, strategy, and technical professionals a practical and technology-
neutral framework for methodical consideration of their own decentralized, blockchain-based web3
solution concepts. No specialist knowledge is assumed. The document can be read from start to
finish, or readers can follow hyperlinked cross-references (e.g., Characterizing Web3 Solution
Decentralization) to focus on material most relevant to them.
We begin with the following sections:
Web 1, 2, 3 (section 1.1)
Fundamental Web3 Capabilities (section 1.2)
Likely Web3 Problem Domains (section 1.3)
Simplified Web3 Solution Model (section 1.4)
Organization of the Document (section 1.5)
1.1 Web 1, 2, 3
Figure 1 visualizes Web1, Web2 and Web3.
Figure 1 Web1, Web2 and Web3 (from (1) and (2))
Web1 was based on content generated and controlled by hosts publishing webpages which
users read via their browsers. Web1 search engines like Yahoo! linked users to static web
pages. Web1 popularized the notion of the internet as the “information superhighway” and
the information economy.
Web2 permitted users to upload, or write, content. Beyond simple blogging, users
embraced the ability to post personal status (e.g., Facebook), personal opinions (e.g.,
-generated content
Host-generated authority
oStatic content
Information Economy
-generated content
oHost-generated authority
Centralized execution
Platform Economy
oUser-generated content
-generated authority
Decentralized execution
via Smart Contracts
Token Economy
Practical Web3 Solution Considerations
Page 4
Twitter), personal pictures (e.g., Instagram), product and service reviews (e.g., Yelp,, TripAdvisor), contribute to prosocial activities (e.g., Wikipedia, open-source
projects), and much more. User generated content was then controlled by firms hosting
web2 platforms like Facebook.
Web3 - according to Wikipedia web3 is ‘an idea for a new iteration of the World Wide Web
based on blockchain technology, which incorporates concepts such as decentralization and
token-based economics’1. Web3 gives users more control and authority over their content
via protocols based on cryptographic signatures and hashes (2). Blockchain and Smart
Contracts of web3 enable cryptographic tokens which enables token economies and
cryptocurrencies. Web3 also creates decentralized mechanisms for social, economic, and
political coordination, which can disrupt traditional organizational models.
Bitcoin cryptocurrency is suggested as the first web3 solution. The success of Nakamoto’s
Bitcoin: A peer-to-peer electronic cash system
(3) demonstrated that commercial transactions
could be executed reliably across the internet by a decentralized network of untrusted actors.
Crucially, Nakamoto solved the double spending problem (i.e., spending the same electronic cash
twice) without a centralized authority. Key features demonstrated by Bitcoin which are generalized
in web3 decentralized solutions include:
Decentralized consensus of transaction validity achieved via a pool of untrusted actors
Immutability of transactions
Transparency of transactions for all actors
No centralized, trusted intermediary, which can increase costs, prolong processing times,
and create single points of failure
Ethereum added a Smart Contracts workflow scripting mechanism that enabled automated
transaction processing via on-chain data. Blockchain-based data coupled with Smart Contracts
enables fundamentally decentralized web3 solutions in which peer-to-peer interactions between
actors replace web2-style centralized applications.
1.2 Fundamental Web3 Capabilities
Decentralized web3 solutions are likely to exploit some of the following fundamental web3
Disintermediated, peer-to-peer interactions – rather than centralized gatekeeper
platforms intermediating transactions and taxing value, web3 enables actors to directly
1 retrieved 2022-06-06.
Practical Web3 Solution Considerations
Page 5
interact, for example: artists can directly connect with their fans; borrowers can directly
connect with lenders; and ride hailing drivers can directly connect with riders.
Decentralized and distributed execution of applications, which are often called Smart
Contracts or Decentralized Applications (DApps).
Internet-native cryptotoken payment and settlement – payment can be automated via
web3 Smart Contracts using Fungible Tokens. Think of fungible cryptographic tokens like
casino chips: one buys them when entering a casino (think a web3 solution); one effortlessly
uses them for gaming (think transacting via Smart Contracts); and one can redeem them on
demand for fiat currency (think US dollars).
Transparency, traceability, and immutability of transaction data, which facilitates auditing.
Single source of truth for who owns what, who owes what, etc. – a single source of truth
enables workflow synchronization across multiple organizations, which can accelerate
movement of products and services across a value chain. Actors can audit blockchain data
to independently verify truth.
Self-sovereign data ownership – centralized web2 platforms like Facebook require users to
cede ownership rights of content they share via the platform. Decentralized web3 models
can enable actors to retain ownership of their content.
Digitalize cooperation and collaboration Smart Contracts enable collaboration and
organizational governance to be programmatically enforced which enables innovative
organizational arrangements like Decentralized Autonomous Organizations (DAO).
Digitalize and industrialize fractional ownership of assets – digitalization and industrial
fractional ownership can make asset ownership attractive to more actors for more classes of
1.3 Likely Web3 Problem Domains
Fundamental Web3 Capabilities are directly applicable to problem domains like:
Asset ownership, including land and property registry
Chain of custody and proof of delivery
Regulatory reporting
Workflow synchronization across multiple organizations
Practical Web3 Solution Considerations
Page 6
Metaverse enablement of trusted user identities and ownership of metaverse-resident
digital assets
Sharing economy enablement, like Sample Web3 Solution: Ride Hailing
Peer-to-peer (i.e., disintermediated) marketplaces
Digital rights management
Escrow systems
Cryptocurrency-based payment and settlement
Peer-to-peer lending
Censor-proof information sharing and free speech applications (4)
Self-sovereign identity, which gives individuals control of their digital identities2
Digitalizing organizational governance
Digitalized reputation systems
eGovernment, including transparency of government procurement processes, voting, etc.
Coordination and monetization of resource (e.g., spectrum) sharing
1.4 Simplified Web3 Solution Model
Figure 2 illustrates the Simplified Web3 Solution Model that is used in this monograph. Although
many Likely Web3 Problem Domains are not buyer/seller paradigms, this model will be familiar to
many readers via our Economic Decentralization Example: Multiple Listing Service of section 2.4.
2 retrieved 2022-08-05.
Practical Web3 Solution Considerations
Page 7
Figure 2 Simplified Web3 Solution Model
1) Buyers (e.g., Users) primarily consume resources and services offered by sellers via the
web3 solution. Buyers often bring revenue to the solution.
2) Sellers (e.g., Resource Providers) primarily offer resources and services for buyers to
consume. Sellers (e.g., Resource Providers) often expect to earn revenue via the solution.
Like prosumers, a Decentralized Solution Ecosystem actor can simultaneously engage as
both a buyer (i.e., User or Power (Web3) User) and seller (i.e., Resource Provider or Power
(Web3) Provider).
3) Decentralized web3 system includes the blockchain, smart contract execution engine
and other elements that facilitate value exchange between buyers and sellers.
4) Buyers and Sellers interact with the decentralized system via web3 protocol interactions,
especially posting transactions to the blockchain and executing smart contracts.
5) Decentralized peer-to-peer interactions can occur directly between Buyers and Sellers,
rather than being mediated by a centralized gatekeeping intermediary.
1.5 Organization of the Document
The document is organized as follows:
Decentralization (chapter 2) explains the difference between traditional, centralized
web2 systems and decentralized web3 solutions. Functional Decentralization, Solution
Decentralization, Characterizing Web3 Solution Decentralization and Drawbacks of
Decentralization are explicitly considered.
Decentralized System
actors who
consume/buy value
actors who
offer/sell services
or resources
Web3 Protocol Interactions
Blockchain & Smart Contract Execution Engine
Practical Web3 Solution Considerations
Page 8
Blockchain (chapter 3) reviews Blockchain Basics, Transactions, Consensus, Types of
Blockchains and Drawbacks of Blockchain.
Smart Contracts (chapter 4) introduces Smart Contracts which automate execution of
multiparty workflows. Agreements, Decentralized Applications (DApps), Transaction Costs
and Smart Contract Costs are explicitly considered.
Oracles (chapter 5) review Types of Blockchain Oracles, Oracle Design Patterns, Oracles
and the Fundamental Problem of Smart Contracts and Legal Concerns with Oracles.
Tokens (chapter 6) considers Tokens, Tokenization, Benefits of Asset Tokenization,
Money, Cryptocurrency and Stablecoins.
Decentralized Solution Ecosystem (chapter 7) introduces roles and motivations of actors
in a decentralized web3 solution ecosystem.
Token Economics (chapter 8) considers the Value Exchange Model that motivates
Decentralized Solution Ecosystem actors to willingly engage with a web3 solution.
Kickstarting a Use Case (chapter 9) sketches the Recipe for Creating a Use Case via a
Pizza Delivery Use Case, as well as Bootstrapping the Use Case.
Leadership (chapter 10) consider Leader Responsibilities, Network Effects and other
Web3 Leadership Challenges facing the Leader of a decentralized web3 solution.
Governance (chapter 11) consider governance of a decentralized web3 solution, including
Layered Governance Model , Disclosure and Transparency, Jurisdiction-Driven
Governance Responsibilities and Jurisdiction-Driven Governance Responsibilities.
Trust (chapter 12) methodically consider what Trust means and how it operates.
Dimensions of Trust, Trust Workflow, Trust Cues, Trust Model and Trust Evaluation are
Solution Trustworthiness (chapter 13) consider the Trust necessary for actors to
voluntarily engage with a decentralized solution, including System Trustworthiness,
Ethical System Model, Counterparty Trust Cues, Oracle Trust Cues, Smart Contract Trust
Cues and Governance Trust Cues.
Boundary Resources (chapter 14) consider the knowledge and artifacts that enable
different types of Decentralized Solution Ecosystem actors to effectively share
knowledge and create value via a web3 solution.
Indicators (chapter 15) methodically consider the Measurement Information Model that
supports the information Decentralized Solution Ecosystem actors need to manage their
objectives, goals, risks, and problems of engaging with the decentralized web3 solutions.
Practical Web3 Solution Considerations
Page 9
Regulatory and Compliance Considerations (chapter 16) reviews legal and regulatory
compliance considerations for decentralized web3 solutions.
Decentralized Autonomous Organizations (chapter 17) consider the Historical Context,
Aspiration, Characteristics, DAO Governance Model and Fundamental DAO Risks of smart-
contract-based Decentralized Autonomous Organizations.
Your Web3 Solution (chapter 18) sketches fundamental questions to consider when
formulating a web3 solution offer concept to serve some use case.
Creative Destruction (chapter 19) frames web3 as a new form of industrialization
organization that will complement the metaverse and the fourth (cyber-physical)
industrial revolution.
Acknowledgements (chapter 20)
References (chapter 21)
Practical Web3 Solution Considerations
Page 10
2 Decentralization
Chapter Objective: explain the difference between traditional, centralized web2 systems and
decentralized web3 solutions. Functional Decentralization, Solution Decentralization,
Characterizing Web3 Solution Decentralization and Drawbacks of Decentralization are explicitly
Decentralization is the opposite of centralization. For example, rather than centralizing political
power in a central committee ruling a jurisdiction, power can be decentralized or devolved to states,
counties, municipalities or even individuals. This chapter considers web3 decentralization in the
following sections:
Political Centralization and Decentralization (section 2.1)
Functional Decentralization (section 2.2)
Economic Centralization (section 2.3)
Economic Decentralization Example: Multiple Listing Service (section 2.4)
Sample Web3 Solution: Ride Hailing (section 2.5)
Solution Decentralization (section 2.6)
Drawbacks of Decentralization (section 2.7)
Characterizing Web3 Solution Decentralization (section 2.8)
2.1 Political Centralization and Decentralization
means to concentrate by placing power and authority in a center or central
organization3. Totalitarian governments are extreme forms of centralization in which the dictator,
junta or ruling council exerts total control over resources, people, laws, and governance within their
country’s border.
means the dispersion or distribution of functions and powers, especially the
delegation of power from a central authority to regional and local authorities4. Anarchy (a state of
lawlessness or political disorder due to the absence of governmental authority5) is an extreme form
of political decentralization. Decentralization is a relative concept to characterize how far power
and authority are devolved away from a single central decision maker.
Consider governance of public schools. Curriculums and graduation requirements must be set,
textbooks must be selected, qualified teachers and administrators must be hired, cafeteria menus
must be selected, and countless other decisions must be made. Figure 3 visualizes the
fundamental options for making each of those governance decisions:
3 retrieved 2022-10-31.
4 retrieved 2022-10-31.
5 retrieved 2022-10-31.
Practical Web3 Solution Considerations
Page 11
Figure 3 Spectrum of Public-School Governance Options
1) National authority
2) State authority
3) Local school board, often directly elected by local voters
4) School principals, often hired by local school board
5) Teachers & administrators, often hired by school principals
Each jurisdiction decides how much to decentralize governance and control of their public
schools. Reasonable individuals can disagree about the appropriate level of political
decentralization, and decentralization preferences often change across time as societal, political,
and economic factors change.
2.2 Functional Decentralization
Decentralized system
means ‘wherein control is distributed among the persons or organizations
participating in the operation of the system’ (5). Figure 4 illustrates how the functional architecture
of a traditional application solution could change when shifting from a centralized application
architecture to a fully decentralized smart contract- and blockchain-enabled solution.
(e.g., Dictatorial
Teachers &
(e.g., Anarchy)
Practical Web3 Solution Considerations
Page 12
Figure 4 Functional Decentralization of an Application Solution (based on (6))
1) Presentation Layer - the front-end web servers and apps of centralized web2
applications are controlled by a single entity; for example, Uber controls the apps that
give riders and drivers access to Uber’s ride sharing marketplace. Decentralized web3
solutions enable several different entities to give actors access to solution functionality;
in our Sample Web3 Solution: Ride Hailing of section 2.5, riders and drivers can access the
decentralized ride hailing solution via different Service Providers (RiderCo and DriverCo).
2) Business Logic Layer – the business logic layer for centralized web2 applications is
implemented on servers operated and controlled by a single entity using the entity’s
proprietary software; for example, Uber’s business logic matches drivers to riders using
Uber’s proprietary software. For decentralized web3 solutions the business logic layer is
implemented via Smart Contracts hosted on a Blockchain; in our Sample Web3 Solution:
Ride Hailing matching rider Alice with driver Bob is implemented via decentralized
interactions between RiderCo and DriverCo, and is ultimately codified via smart contracts
on the solution’s Blockchain.
Logic Layer
Data Storage &
Single entity controls all
Digital Solution
Multiple entities
control all layers
Nexus of smart
Application Server
Database Server Data stored in a peer-
to-peer network
and Password
Practical Web3 Solution Considerations
Page 13
3) Data Storage & Management Layer – data for centralized web2 applications is stored
and managed by a single entity; for example, Uber maintains profiles for all drivers and
riders, records all ride hailing transactions, and huge volumes of metadata like the
location of all actors as they use the Uber application. For decentralized web3 solutions,
data is stored on a peer-to-peer storage network like a blockchain. Our Sample Web3
Solution: Ride Hailing solution stores Smart Contracts and Standard Resource
Advertisements on the blockchain.
2.3 Economic Centralization
As shown in Figure 5, web2 platforms are generally organized as centralized gatekeepers that
facilitate economic exchange between buyers and sellers:
Figure 5 Web2 Platform Ecosystem Centralization
Platform Users
have some need and money, like riders engaging with Uber or travelers
engaging with Airbnb.
Platform Complementors
want to be paid for supplying some service or resource, like
drivers with Uber or hosts with Airbnb.
Platform Leader
creates a centralized platform that connects demand from platform
users with supply from platform complementors to create economic value. Web2
platforms are explicitly organized as gatekeepers to take a generous commission on all
transactions (7) and to capture, own and monetize metadata.
Web2 ecosystem platforms enjoy scale efficiencies, so they are explicitly engineered to create
strong positive network effects and achieve winner-take-all outcomes.
is defined as
Platform Users
(typically demand,
like buyers with
Platform Complementors
(typically supply, like sellers)
Centralized (Web2)
Gatekeeper for value
$Platform Leader
(e.g., Uber, Airbnb)
Take a commission on all
Capture, own and
monetize metadata
Practical Web3 Solution Considerations
Page 14
exclusive ownership through legal privilege, command of supply, or concerted action6. Dominant
web2 platforms become monopolies that can dictate the terms of value exchange, which diminishes
the agency of sellers and the options for buyers. For example, Uber sets the fare that drivers may
earn rather than permitting them to set or negotiate their own fares.
Uber and other centralized web2 customer-to-customer sharing economy platforms have been
pilloried for exploiting workers, weakening social capital, negative externalities, and other societal
ills. For example, a 2013 piece in the Financial Times claimed that Uber and other web2 sharing
economy platforms ‘amplify the worst excesses of the dominant economic model: it is neoliberalism
on steroids’ (8).
Economies of scale and monopolistic tendencies drive many businesses to maximize their
market share so they can exert maximum leverage on their suppliers and maximize revenue
extraction from their customers. However, economic decentralization can create vibrant,
competitive, and liquid markets, as residential real estate via multiple listing services.
2.4 Economic Decentralization Example: Multiple Listing Service
Residential properties in the US and other jurisdictions are often sold via a decentralized
marketplace called a Multiple Listing Service (MLS) mechanism that real estate agents use to a
establish a deep and liquid market for real estate transactions. For comparison, the traditional
alternative to a decentralized multiple listing service real estate marketplace is a system of
exclusive (i.e., centralized) real estate listings in which a single (i.e., central) broker handles both
sides of the real estate transaction. Exclusive listings limit the pool of potential buyers for a seller’s
home and creates a conflict of interest because the central agent is unlikely to be simultaneously
acting in the best interest of both the buyer and seller. Unsurprisingly, few sellers opt for exclusive
listings when they could use MLS to expose their property to the largest pool of prospective buyers.
Figure 6 visualizes how a multiple listing service facilitates real estate transactions.
6 retrieved 2022-10-31.
Practical Web3 Solution Considerations
Page 15
Figure 6 Facilitating Real Estate Transactions via MLS
1) Each home seller selects one of the many real estate brokers operating in their area to
sell their house. Call that broker the
selling agent
2) The selling agent posts a standard advertisement for the house to the local MLS homes
for sale database.
3) All real estate brokers in the area can see all homes for sale advertised in the MLS
4) Each prospective homebuyer selects one of the many real estate brokers operating in the
area to help them find a house. Call that broker the
buying agent
. The buying agent
searches homes for sale in the multiple listing service database to find properties fitting
the prospective buyer’s needs and organizes property visits.
5) Offers from prospective buyers to sellers are negotiated peer-to-peer between buying
agent and selling agent. Eventually a buyer and seller agree, and the sale is completed.
Figure 7 visualizes the typical money flow for a decentralized real estate transaction:
Multiple Listing Service
Buyers Sellers
Homes for Sale
Practical Web3 Solution Considerations
Page 16
Figure 7 Money Flow for Decentralized Real Estate Transaction
1) Buyer pays the agreed selling price.
2) Seller receives the agreed selling price, minus commissions for buying agent and selling
3) Buying agent receives nominally 3% of selling price.
4) Selling agent receives nominally 3% of selling price.
5) Both buying agent and selling agent pay a membership fee to use MLS to advertise and
search homes for sale.
Decentralized MLS systems have worked in the United States for a century because member real
estate brokers agree that maximizing the depth and liquidity of the real estate market, as well as
minimizing friction of property sales, increases the aggregate real estate market, and a bigger
market helps all real estate brokers. The decentralized marketplace enables smaller brokers and
individual realtors to vigorously compete on service and commissions.
2.5 Sample Web3 Solution: Ride Hailing
Figure 5 Web2 Platform Ecosystem Centralization offered Uber as an exemplar for digitalized
Economic Centralization. Decentralization shifts power away from centralized web2 platforms (e.g.,
Uber) to actors who create value (e.g., drivers) and consume value (e.g., riders). Blockchain and
Smart Contracts technology enable digitalization and enhancement of the fundamental business
model of section 2.4 Economic Decentralization Example: Multiple Listing Service.
Buyer 1
Multiple Listing Service
Practical Web3 Solution Considerations
Page 17
Figure 8 Hypothetical Wikirides Decentralized Web3 Ride Hailing
Figure 8 sketches a hypothetical decentralized web3 ride hailing solution we’ll call Wikirides, which
gives drivers more control over their work and eliminates quasi-monopolistic controls and
commissions dictated by centralized platforms like Uber.
1. Driver Bob has selected the Wikirides app from Service Provider DriverCo because it
combines the features he needs with low fees. Bob loads the DriverCo app on his
smartphone, registers and confirms that he is available to serve riders. DriverCo then posts
information about Bob’s availability to the Wikirides blockchain.
2. Rider Alice has selected the Wikirides app from Service Provider RiderCo because it offers
the features she needs. Alice downloads RiderCo’s app to her smartphone, registers and
requests a ride via her smartphone.
3. RiderCo’s application backend then searches for Wikirides drivers who may be willing to
transport Alice to her desired destination. Potentially dozens of drivers are identified.
4. RiderCo sends a standard request to each driver’s Wikirides Service Provider (e.g., DriverCo
for Bob). The request includes the pickup location, drop off destination and number of
5. Like other Wikirides Service Providers, DriverCo receives the standard request for Bob and
compares it against Bob’s preferences and availability. Bob is available and the ride
conforms to Bob’s preferences, so DriverCo notifies Bob of the ride request and suggests a
Wikirides Blockchain
Validator 1
Blockchain Node
Validator 2 Validator N
Web3 Style Interactions
Smart contract
books driver and
automates payment
as smart
Display sorted
quotes to user
User requests a ride
RiderCo searches
blockchain for
relevant drivers
quote from
Quote selected by
user is posted to
blockchain as smart
Practical Web3 Solution Considerations
Page 18
fare to bid. If Bob decides to bid for the ride, then DriverCo returns Bob’s bid to RiderCo as
a smart contract with the fare agreed by Bob.
6. RiderCo aggregates all the bids from drivers and sorts them according to Alice’s preferences.
For example, Alice may prefer to be transported in electric vehicles and by drivers who
identify as female, so RiderCo renders the bids in the most useful order for Alice. RiderCo’s
app enables Alice to inspect trust cues for drivers, like seeing their ratings, information on
their vehicle and so on.
7. Alice selects Bob’s fare, so the smart contract returned by DriverCo for Bob’s fare is posted
to the Wikirides blockchain by Alice’s Service Provider RiderCo.
8. Execution of Bob’s smart contract notifies Bob (via DriverCo) that he has been awarded the
ride. RiderCo shares Alice’s exact location (from the RiderCo app) with Bob to coordinate the
pickup. The smart contract monitors the location of both Bob’s and Alice’s phone for the
duration of the ride. When Alice arrives at her destination and Bob drives off, the smart
contract deems the ride complete and automatically transfers payment from Alice’s crypto
wallet to Bob’s.
Figure 9 visualizes Sample Money Flow for Hypothetical Wikirides Decentralized Web3 Ride
Figure 9 Sample Money Flow for Hypothetical Wikirides Decentralized Web3 Ride Hailing
1) The full fare RiderCo offered User Alice for Resource Provider Bob’s ride was $1.00,
which Alice pays at the conclusion of the ride.
Wikirides Solution Leader
Alice 1
Membership fee
Practical Web3 Solution Considerations
Page 19
2) Buy-side Service Provider RiderCo earns a small commission on rides they facilitate, so
RiderCo passes $0.95 to Bob’s sell-side Service Provider DriverCo.
3) Sell-side Service Provider DriverCo earns a small commission on the fair and pay
Resource Provider Bob $0.90 for driving User Alice.
4) Service Providers RiderCo and DriverCo both operate Wikirides Validator nodes so they
pay only a small annual fee to the Wikirides solution Leader for the privilege of directly
engaging with the Wikirides blockchain to organize rides. Service Providers that do not
host a Wikirides Validator node pay a higher annual membership fee.
As explained in chapter 10 Leadership, the Wikirides Leader is organized as a non-profit
corporation, so Wikirides operates on a service-at-cost basis with each Service Provider paying an
annual membership fee to advertise drivers and book rides. The Wikirides Leader sets the Service
Provider membership fee discount for firms operating Wikirides Validator nodes so that sufficient
Validator nodes assure reliable and trustworthy operation of Wikirides.
2.6 Solution Decentralization
Engineers suggest that decentralizing digital systems can bring several technical benefits (9):
Fault tolerance, such as when systems are physically separated to create geographic
Attack resistance, such as when workloads can be easily shifted from compromised
systems to intact systems.
Collusion resistance because conspiracy is more challenging when more independent and
dispersed actors must cooperate. Note that (1) Blockchain consensus algorithms
explicitly focus on this benefit for transactions and (2) execution of decentralized Smart
Contracts focuses on this benefit for applications.
Blockchain and Bitcoin were initially motivated by
crypto anarchism
(a political ideology focusing
on protection of privacy, political freedom, and economic freedom) and used cryptographic
software for confidentiality and security while sending and receiving information over computer
networks7. Bitcoin’s first killer app was anonymously and untraceably settling payments for drugs on
Silk Road8, and later settling ransomware payments.
Web3 decentralization is now motivated by the Fundamental Web3 Capabilities of section 1.2,
Disintermediated, peer-to-peer interactions
7 retrieved 2022-11-01.
8 See
Practical Web3 Solution Considerations
Page 20
Internet-native cryptotoken payment and settlement
Transparency, traceability, and immutability of transaction data
Single source of truth for who owns what, etc.
Self-sovereign data ownership
Digitalize cooperation
As shown in Figure 10, there is a spectrum of decentralization options for digital platforms:
Figure 10 Spectrum of Digital Platform Centralization Options
Extreme centralization
of a web2 walled garden platform in which the platform leader:
Can achieve scale (e.g., Facebook) and operational efficiency
Dictates often monopolistic and perhaps exploitive terms of use
Owns and controls user-generated content and user metadata
Monitors and monetizes all actor-to-platform and actor-to-actor interactions
Extreme decentralization
can result in crypto anarchism, which easily devolves into a
dystopian swamp of anonymous hate speech and offensive content, criminal activity, and
unsavory behaviors, like paying Bitcoin ransoms to cybercriminals with no legal recourse.
decentralization is between the extremes of centralization and decentralization,
and potentially offers actors:
Reasonable user agency and empowerment
Lawful engagement so actors are not encumbered with unacceptable compliance or
reputational risks
Extreme Centralization
(e.g., Web2 Walled Garden)
Extreme Decentralization
(e.g., Bitcoin)
Total anonymity
Total freedom of speech
Total freedom to trade
No legal recourse
Monopolistic, and perhaps
exploitive, terms of use
Platform owned and
curated content
Actor interactions
monitored and monetized
User agency and empowerment
Fair and Ethical
Transparent and open
Permissionless innovation
21 3
Practical Web3 Solution Considerations
Page 21
Trustworthy engagement so actors willingly engage with the solution and
Fair and ethical governance of user interaction and value exchange
Community contributes to governance decisions rather than having a centralized
authority unilaterally dictate all policies
Transparent and open, so community is informed and can appropriately engage
Permissionless innovation, so user can (co)create value
The goal of a
web3 solution should not be to maximize decentralization but to provide
sufficient decentralization to address the mission of the solution and benefit Decentralized
Solution Ecosystem actors while minimizing the Drawbacks of Decentralization.
2.7 Drawbacks of Decentralization
While devolving control and decision making closer to the actors using the solution has benefits
discussed in earlier sections, decentralization has several inherent drawbacks, which should be
appropriately considered:
Complexity of coordination and synchronization – coordinating and synchronizing
collaboration and multi-actor activities is more complex without a centralized authority,
system, or project manager.
Unclear accountability when things go wrong – a single, centralized authority often
becomes the one-throat-to-grab when things go wrong; however, in a decentralized
solution simply identifying the proper throat-to-grab to resolve a problem may become
Inefficiency – decentralizing activities undercuts the scale efficiencies that come from
centralization because infrastructures to support decentralized activities must be
replicated across the entities responsible for those devolved activities.
Corruption – decentralizing decision-making and other activities makes it easier to avoid
oversight, so corruption may increase.
Legal and Regulatory Institutional Voids uncertainties about regulatory treatment of
cryptocurrencies, legal standing of smart contracts, web3 fundraising practices and many
other topics create compliance and reputational risks for enterprises and natural persons
engaging with web3 solutions. Eventually policies, regulations and governmental
enforcement mechanisms will cover web3 activities, and this drawback will disappear.
Kickstart Problem – entrepreneurs and investors eagerly created centralized web2
platforms like Uber, which aspired to create strong positive network effects to achieve a
winner-take-most market position so they could then extract monopoly rents on all
Practical Web3 Solution Considerations
Page 22
transactions flowing through their platform. Since decentralized web3 platforms don’t
offer the prospect of juicy investment returns via monopoly rents, it is harder to organize
firms or natural persons to contribute to the Leader organization rather than simply
freeriding on the decentralized solution once others have created it.
2.8 Characterizing Web3 Solution Decentralization
decentralization from section 2.1 Political Centralization and Decentralization can be
usefully characterized along three dimensions (10):
decentralization for the degree of taxation and spending decisions made locally
decentralization for the degree of policy creation and interpretation devolved to
local authorities
decentralization for the degree of operational control devolved to local
decentralization is usefully characterized along the following dimensions:
actor-to-actor value creation and exchange
– degree of control Decentralized Solution
Ecosystem actors, especially Users, Resource Providers, Power (Web3) Users, Power
(Web3) Providers, and Service Provider have to create and exchange value via peer-to-
peer communications instead of requiring an intermediary not voluntarily chosen by the
actor. For example, User Alice in our Sample Web3 Solution: Ride Hailing voluntarily
chooses Service Provider RiderCo, but she could switch to any of RiderCo’s competitors
and continue to enjoy the benefits of Wikirides.
distribution of value
– portion of economic value retained by Resource Provider rather
than distributed to solution Leader, Validator(s), Oracle Provider(s), Service Provider(s)
and other actors.
ownership and control of user data
– degree of control actor has for their data and
metadata. Decentralization suggests that creators should have ownership and control of
their data/content, while centralization implies that a central actor retains ownership and
control of data/content created by other.
participation in governance decision-making
– degree of possible influence an actor has on
governance decisions. Practically, a single malign or disgruntled actor should not be able
to unilaterally impose their will on other actors.
– scope of information actors have about governance policies and decisions
robustness and fault tolerance
– can the solution be disrupted by a single actor or
Practical Web3 Solution Considerations
Page 23
presence of trusted intermediaries
– while a single centralized web2-style gatekeeper
does not exist in a decentralized solution, trusted intermediaries may still exist, like
Service Providers which host crypto wallets for Users. Note that the Power (Web3) User
and Power (Web3) Provider roles engage directly via web3 protocols without going
through a Service Provider.
Practical Web3 Solution Considerations
Page 24
3 Blockchain
Chapter Objective: review Blockchain Basics, Transactions, Consensus, Types of Blockchains and
Drawbacks of Blockchain.
A blockchain is a distributed ledger of transactions that all actors can inspect, but which no single
actor controls. As the name implies, blockchain is an append-only ledger with a built-in distributed
consensus mechanism which establishes confidence in the correctness and immutability of on-chain
data. Blockchain enables actors to hold and transfer value in a digitally native format (e.g., digital
assets or cryptocurrency) via Smart Contracts without the need for trusted intermediaries.
Blockchain is fundamentally about facilitating transactions between untrusting parties like
producers and consumers, buyers and sellers, and strangers in general.
This chapter is organized as follows:
Blockchain Basics (section 3.1)
Transactions (section 3.2)
Consensus (section 3.3)
Types of Blockchains (section 3.4)
Drawbacks of Blockchain (section 3.5)
3.1 Blockchain Basics
As shown in Figure 11, a blockchain is a continuous daisy chain of data blocks that start from a
genesis block.
Figure 11 Sample Blockchain
Each block contains:
Hash of Block
Hash of Block
Hash of Block
Hash of Block
Transaction 1
Practical Web3 Solution Considerations
Page 25
1) Parent block hash, which is a cryptographic checksum of the previous block. These
checksums are the cryptographic armor that protects transaction data from retrospective
2) Timestamp when the block was added to the chain.
3) Nonce (i.e., sequence number) of this block.
4) A set of validated transaction records in the body of the block.
Because each block contains a cryptographic hash of the proceeding block and each block is
replicated across many Validator nodes, it is infeasible to retroactively alter blocks without the
consent of most Validators and alteration to all subsequent blocks. Thus, actors have high
Confidence in the immutability of Transactions written to the blockchain.
Blockchain is a type of distributed ledger technology (DLT), meaning a ledger that is shared
across a set of ledger nodes and synchronized between the ledger nodes using a Consensus
mechanism (5). ‘A distributed ledger is designed to be immutable, tamper-resistant, tamper-
evident, and append-only, containing final and definitive ledger records of confirmed and validated
transactions’ (5).
3.2 Transactions
is the ‘smallest unit of a work process, which is one or more sequences of actions
required to produce an outcome that complies with governing rules… [a] transaction is understood
more narrowly, as the smallest unit of a work process related to interactions with distributed
ledgers’ (5). Transactions posted to a blockchain ledger capture information like: ownership and
transfers of cryptograph Tokens; Smart Contracts; and status returned by Oracles.
Basic blockchain transaction workflow is:
1. Propose transaction – an actor requests a new transaction.
2. Send proposed transaction to network of computers – the signed transaction is broadcast
to all the blockchain’s validator nodes.
3. Nodes verify proposed transactionValidator nodes apply the Consensus algorithm to
reach agreement on the validity of the proposed transaction.
4. Add verified transaction to new block – validated transaction is aggregated or coalesced
with other transactions into a new block.
5. Append new block to the blockchain – new block is attached to the blockchain.
6. Complete transaction – committed transaction is visible to all in the newly committed block.
Practical Web3 Solution Considerations
Page 26
3.3 Consensus
means ‘agreement among DLT nodes a transaction is validated; and that the
distributed ledger contains a consistent set and ordering of validated transactions. Consensus
does not necessarily mean that all DLT nodes agree’ (5).
Consensus on the Truth and validity of Transactions underpins myriad economic activities.
Blockchain is engineered so that users can trust the consensus process rather than having to trust
an intermediary like a bank, notary or centralized web2 platform. The foundational magic of
blockchain is:
(1) establishing Consensus on Transactions across a decentralized pool of validators; and
(2) maintaining an immutable, persistent, and transparent record of those Transactions.
The consensus protocol includes mechanisms to resolve problems like double-spending and
fraudulent transactions. Nodes hosting blockchains and validating transactions are called miners or
Validators. Each blockchain solution chooses the consensus algorithm for those Validators to use.
Bitcoin’s proof-of-work algorithm is the best-known consensus model, but proof-of-stake,
delegated-proof-of-stake, various Byzantine fault tolerance arrangements, directed acyclic graphs
and other mechanisms can be used. Some qualified majority of peer-to-peer actors apply the
consensus algorithm and must agree on the validity of each block.
Since executing the consensus mechanism and replicating a blockchain consumes resources,
some incentive or payment mechanism for the Validator is required, such as:
o Bitcoin miners compete to win newly minted bitcoins.
o Ethereum users pay transaction fees in $ETH cryptocurrency.
o Consortium blockchains could require that each member must validate at least two
transactions from other actors for each transaction they submit.
o Decentralized Solution Ecosystem actors who host a Validator node may receive a discount
on membership fees to use the solution.
3.4 Types of Blockchains
Figure 12 visualizes of a blockchain model based on classification system of (11):
Practical Web3 Solution Considerations
Page 27
Figure 12 Blockchain Classification Model (based on (11))
1) Function – a blockchain implementation can be engineered for a single application (i.e.,
) like the Bitcoin blockchain, which is engineered for cryptocurrency
payments in Bitcoin or can be engineered as a
like Ethereum, which can support
different smart contract-based applications.
2) Usage – a blockchain can be
so anyone may join the network and see information
on the blockchain or
so that only chosen members can see information on the
3) Validation model can be
so any actor can become a validator like how
anyone can become a Bitcoin miner, or it can be
so only actors chosen by
the Leader or via some selection mechanism can become validators.
4) Consensus model used by validators to agree on what should be added to the blockchain
and the truth of blockchain contents. Popular consensus models include: Proof-of-Work,
which is currently used by Bitcoin; Proof-of-Stake, which is used by Ethereum after the
Merge; and Practical Byzantine Fault Tolerance (12), which is used by Hyperledger Fabric.
3.5 Drawbacks of Blockchain
Blockchain technology is not a general data storage solution, and certainly not an alternative to
traditional database management systems. While many use cases benefit from the shared,
Anyone may see
information on
the blockchain
Only chosen users may
see the information on
the blockchain Proof of Work
Miners compete to
solve a mathematical
Proof of Stake
Validators indicate
the stake they have
in the blockchain
Practical Byzantine
Fault Tolerance
Blockchain used
for only one
specific application
Numerous applications
can be put on top of the
Anyone may become
a validator
Only chosen actors may
become validators
3 4
Practical Web3 Solution Considerations
Page 28
immutable, append-only transaction ledger, one must recognize the drawbacks of blockchain
Latency – transactions only become visible once consensus has been reached by the
chain’s Validators on the new block that contains the transaction. Blockchain cycle time
to create and validate new blocks is often every few minutes, so low latency transactions
may be infeasible.
Transaction size – blockchains aren’t built for storing very large objects, like MPEG-4
movies. Instead, large data objects can be stored using IPFS9 or other mechanism and a
small blockchain transaction can record a pointer to that data object and a cryptographic
checksum (a.k.a., hash) of the data object’s contents.
Transaction throughput – blockchains aren’t currently engineered to support high
transaction volumes.
Inefficiency – establishing consensus on transaction validity across a community of
untrusting actors is inherently inefficient. While traditional redundancy often arranges
two or more trusted nodes to process every transaction, blockchain Consensus models
use significantly more than two untrusted nodes to validate transactions. Thus,
blockchain Consensus inherently requires more untrusted nodes to validate transactions
than would be necessary if nodes could be trusted.
Compliance and Immutability – blockchain immutability makes it difficult to expunge a
transaction which can create compliance challenges. For example, if child sexual abuse
material (CSAM) or other prohibited matter was incorporated into a transaction in a
validated block on the chain, then removing that material from the blockchain to comply
with lawful authorities may be infeasible.
Note that other distributed ledger technologies address some of these drawbacks better than
blockchain technologies.
9 ‘The InterPlanetary File System (IPFS) is a protocol, hypermedia and file sharing peer-to-peer network for storing
and sharing data in a distributed file system’. retrieved 2023-02-
Practical Web3 Solution Considerations
Page 29
4 Smart Contracts
Chapter Objective: introduce Smart Contracts, which automate execution of multiparty
workflows. Agreements, Decentralized Applications (DApps), Transaction Costs and Smart Contract
Costs are explicitly considered.
“Smart contracts” is one of the worst marketing labels in history.
David G.W. Birch
They’re Not Smart and They’re Not Contracts
FORBES September 4th, 2021
Smart contract
is a ‘computer program stored in a distributed ledger technology (DLT) system
wherein the outcome of any execution of the program is recorded on the distributed ledger. A
smart contract can represent terms in a contract in law and create a legally enforceable obligation
under the legislation of an applicable jurisdiction’ (5). Practically, a smart contract is self-executing
code and self-enforcing application-specific workflows that exist on a blockchain network (13).
This chapter considers Smart Contracts in the following sections:
Agreements (section 4.1)
Decentralized Applications (DApps) (section 4.2)
Cryptotoken Wallets and Payments (section 4.3)
Transaction Costs (section 4.4)
Smart Contract Costs (section 4.5)
Smart Contract as AI (section 4.6)
4.1 Agreements
is ‘an arrangement as to a course of action’10. We unpack agreements in the
following sections:
Agreement Lifecycle (section 4.1.1)
Temporal Considerations (section 4.1.2)
Characterizing Agreements (section 4.1.3)
Modes of Enforcement (section 4.1.4)
Automating Agreements (section 4.1.5)
4.1.1 Agreement Lifecycle
Figure 13 illustrates the agreement lifecycle:
10 retrieved 2022-06-14.
Practical Web3 Solution Considerations
Page 30
Figure 13 Agreement Lifecycle
1) Search – agreements begin by searching for potential counterparties. For Sample Web3
Solution: Ride Hailing, Service Provider RiderCo deduces Alice’s intent and identifies
potential drivers that can meet her needs. Positive Network Effects will increase the number
of potential counterparties, so efficiency and effectiveness of search must improve as the
ecosystem grows.
2) Design captures price, schedule, terms, and conditions that are acceptable to both parties.
For Sample Web3 Solution: Ride Hailing, Alice and Bob must agree on a fare and accept
Wikirides’ standard terms and conditions.
3) Agreement – both parties agree to transact. For Sample Web3 Solution: Ride Hailing, Alice’s
Service Provider (RiderCo) posts the agreed fare as a smart contract on the Wikirides
4) Monitor adherence to the agreement. For Sample Web3 Solution: Ride Hailing, the RiderCo
and DriverCo apps running on Alice’s and Bob’s smartphones reports their geolocation so
the smart contract can determine when the ride begins and ends. Note that technical (e.g.,
cryptographic) mechanisms would assure that geolocation data is not disclosed to
unauthorized parties.
5) Settle agreement. For Sample Web3 Solution: Ride Hailing, when the smart contract deems
the ride has successfully concluded, payment is automatically transferred from rider Alice’s
wallet to pay driver Bob and relevant transaction fees.
4.1.2 Temporal Considerations
The Agreement Lifecycle is usefully partitioned into several phases (see Figure 14):
For counterparty
1 2 3 4 5
Practical Web3 Solution Considerations
Page 31
Figure 14 Temporal Phases of an Agreement
Ex ante
means ‘based on assumption and prediction and being essentially subjective and
estimative’11 (a.k.a.,
). Actors search for counterparties and design agreements
the agreement event. Ex ante evaluation of counterparty’s Trustworthiness is often
based on assumptions and predictions; for Sample Web3 Solution: Ride Hailing, Alice
assumes that Bob will treat her as well as he treated Bob’s previous customers who gave him
glowing ratings.
Ex post
means ‘based on knowledge and retrospection and being essentially objective and
factual’ 12 (a.k.a.,
). Actors monitor and enforce agreements with
ex post
knowledge and experience of actual counterparty performance. For Sample Web3 Solution:
Ride Hailing, after Alice enters Bob’s car, she begins to gather direct, personal knowledge of
how good a driver Bob really is.
– most agreements are finite and conclude when agreed actions are completed
or the term of agreement expires.
4.1.3 Characterizing Agreements
Agreements are usefully categorized on two dimensions:
Codifiability, meaning how easily the terms of agreement can be formalized, especially as
written code or language. For example, trips organized via Sample Web3 Solution: Ride
Hailing have high codifiability, like
Alice wishes to travel from point A to point B now, and Bob
with transport her for $X
. Some tasks have low codifiability, like
teach my child what justice
11 retrieved 2022-06-08.
12 retrieved 2022-06-08.
Ex Ante
(i.e., prospective phase)
forming an agreement
Ex Post
(ie., retrospective phase)
forming an agreement
For counterparty
Practical Web3 Solution Considerations
Page 32
Verifiability, meaning how easily adherence to the terms of agreement can be verified. For
example, trips organized via Sample Web3 Solution: Ride Hailing have high verifiability via
continuous geolocation monitoring the location of both parties’ cellphones. In contrast,
verifying that your child has correctly learned what
means is far more challenging.
While high codifiability is often possible, humans often leave many details out of agreements ex
post and implicitly rely on counterparty benevolence and integrity to address myriad details ex
ante. For example, one hires a contractor to redo a bathroom without specifying the orientation
and pattern of tiles because one expects that the tile installers will happily accept that design input
just-in-time (i.e., ex post). Higher counterparty Trust enables more details to be omitted from the
ex-ante agreement, which reduces the time and cost of reaching agreement; benevolence and
integrity of both parties should permit ex post clarifications that are acceptable.
Automation of Smart Contracts precludes all or most ex-post clarification of omitted details.
Thus, Smart Contracts are best for
explicit tasks
with high ex ante codifiability and high ex post
verifiability, like our Sample Web3 Solution: Ride Hailing.
4.1.4 Modes of Enforcement
is the ‘proper execution of the process of ensuring compliance with laws,
regulations, rules, standards, and social norms’ 13. Agreements between actors can be enforced via
several mechanisms (14):
1. Contractual mechanisms are based on enforceable promises defining the rights and
obligations of the parties. Contracts are enforced through third parties (e.g., arbitrators,
courts) and government authorities. Contracts are written in legal prose.
2. Relational mechanisms are based on set patterns of behavior to which parties are expected
to conform. Social norms and the ‘shadow of the future’ motivate compliance; for example,
a neighbor helps you today because they may need your help tomorrow. Relational
mechanisms are enforced by the parties themselves. Relational agreements are mostly
informal, but written I owe you notes do exist. Web2 platforms successfully digitalized
relational mechanisms via online ratings and reviews. While a specific rider and Uber driver
are unlikely to transact more than once, the fact that both parties can create a persistent
rating of each other’s behavior creates a visible ‘shadow of the future’ for both parties’
future engagements with the Uber platform.
3. Blockchain smart contract mechanisms rely on self-contained and autonomous systems of
rules encoded as Decentralized Applications (DApps) which are automatically enforced on-
chain by the underlying blockchain-based network. Note that because automated
mechanisms enforce formally coded smart contracts, the probability of incorrect execution
is lower than with contractual or relational mechanisms. However, if a counterparty fails to
13 retrieved 2022-06-08.
Practical Web3 Solution Considerations
Page 33
honor on-chain transaction status, then contractual or relational enforcement mechanisms
will be required.
Practical solutions may organize hybrid enforcement arrangements, especially blockchain-based
Smart Contracts with robust linkages to legally enforceable contract mechanisms. For example,
changing ownership of an on-chain property record is one thing; evicting a squatter from the
physical property to enforce that on-chain ownership is an off-chain problem best handled via
contractual enforcement mechanisms and the local sheriff.
4.1.5 Automating Agreements
Corporations, government agencies and other organizations have traditionally acted through
humans and thus appreciate two problems (15):
1. People do not always follow the rules.
2. People do not always agree on what the rules require.
Non-compliance may be caused by corruption, malfeasance, mistakes, or other reasons, and
often increases risks and/or costs for at least one actor.
Smart Contracts explicitly automate Agreements so human judgement and actions are
eliminated from agreement execution. Thus, execution of Smart Contracts should be more reliable
and predictable than human execution. Note that observant humans may detect flaws when
executing a contract and attempt to take sensible actions, flawed Smart Contracts will be
automatically executed as reliably and predictably as perfect Smart Contracts.
4.2 Decentralized Applications (DApps)
Web3 Smart Contracts are implemented as Decentralized Applications (DApps), which are
‘applications that runs on a decentralized system’ (5), meaning they are executed in parallel on
smart contract execution virtual machines hosted by several Validator nodes. Smart contracts are
programmed in Solidity on Ethereum Blockchains and in chain code on Hyperledger Fabric
Blockchains. Formally specified smart contracts should encode the preferences of the contract
owner and their negotiating partners with respect to decisions under risk or uncertainty. Instead of
being executed by a single trusted intermediary like a bank, smart contracts are executed by
Validator nodes. Blockchain distributed Consensus mechanisms assure that the correct transaction
workflow is produced.
DApps have several characteristics (16):
1) Open source so actors can audit the application.
2) Execution relies on on-chain data for state information and Oracles for off-chain
Practical Web3 Solution Considerations
Page 34
3) Application operations and data are recorded and executed on a decentralized Blockchain
using Smart Contracts.
4) Crypto Tokens are often paid by users to support execution of Decentralized Applications
(DApps). These token rewards are shared by Validator nodes that execute DApps as
sustainable incentive to support DApps.
5) The Decentralized Applications (DApps) execution environment must assure that identities
of relevant actors and other information elements used by DApp processing is authentic.
4.3 Cryptotoken Wallets and Payments
Smart Contracts are engineered to make it easy for parties to transfer cryptographic Tokens
between wallets as payment for value delivered. For example, the Ethereum blockchain facilitates
transfer of cryptographic tokens representing $ETHER between wallets. Smart contract-enabled
transfers of cryptographic tokens representing value makes micropayments feasible, like
instruction-based Execution Fees for Smart Contracts (e.g., Table 1 Selected GAS Fees for Smart
Contract Execution on Ethereum Blockchain).
4.4 Transaction Costs
Compared to traditional, off-chain mechanisms, Smart Contracts are expected to significantly
reduce transaction costs for explicit transactions because:
Ex Ante search for suitable counterparties is cheaper because automated systems can
efficiently search and match codified tasks.
Ex Ante Trust Evaluation of potential counterparties is more effective because blockchain
makes data on actors’ past performance transparently and immutably available for
Ex Ante design and formalization is more rigorous via smart contract languages like
Ethereum’s Solidity.
Ex Post verification via automated monitoring using Oracles and on-chain state information
can be cheaper and more reliable.
Ex Post settlement via automatic transfers of cryptocurrency or other software-triggered
actions can be faster, cheaper, and more reliable.
Ultimately Regulators may permit Blockchain to replace paper-based records of ownership and
Agreements, and Smart Contracts may automate workflows associated with government records
Practical Web3 Solution Considerations
Page 35
4.5 Smart Contract Costs
While Smart Contracts can reduce Transaction Costs, they impose the following costs:
1) Execution Fees (section 4.5.1)
2) Inflexibility Costs (section 4.5.2)
3) Oracle Costs (section 4.5.3)
4) Secure Execution Costs (section 4.5.4)
5) Smart Contract Diligence Costs (section 4.5.5)
4.5.1 Execution Fees
Smart contract code executes on virtual machines hosted by Validator nodes. Those Validator
nodes accrue costs executing actors’ Smart Contracts, so a sustainable business model to cover
Validators’ costs must be arranged. Public blockchains like Ethereum rely on independent Validators
who expect cryptocurrency payment. Ethereum Smart Contracts explicitly pay ‘GAS’ in Wei (10-18
Ether) to execute instructions from Smart Contracts; Table 1 shows Selected GAS Fees for Smart
Contract Execution on Ethereum Blockchain (18):
Table 1 Selected GAS Fees for Smart Contract Execution on Ethereum Blockchain
Name Fee in Wei (10
Gtransaction 21000 Paid for every transaction
Gcall 700 Paid for every CALL operation
Gjumpdest 1 Paid for every JUMPDEST operation
Gsuidice 500 Amount of gas to pay for a SUICIDE operation
While private blockchains may not require explicit pay-as-you-go execution fees like Ethereum
does, Validators’ must still be incentivized to validate actors’ Transactions and execute their Smart
Contracts. For example, each actor may be required to validate some number of other actors’
Transactions and Smart Contracts for each transaction and smart contract that they submit.
4.5.2 Inflexibility Costs
Automating Agreements via Smart Contracts means non-compliance costs are minimized, but
flexibility arising from human judgement is also lost. Inflexibility is problematic regarding (19):
Contractual Incompleteness – all contracts are incomplete and contain gaps. Trustworthy
actors (i.e., benevolent humans with integrity and ability) often quickly reach agreements to
address unexpected ex post situations that are not explicitly covered by the contract.
Without human judgement “the letter of the law” will be followed rather than the spirit of
the agreement, so actors may be disappointed.
Practical Web3 Solution Considerations
Page 36
Flaws in Smart Contracts – bugs are common in new software, so bugs will inevitably exist in
some Smart Contracts. Flaws in Smart Contracts, like triggering cryptocurrency payment on
conditions which can be faked by bad actors, can quickly drain crypto wallets of parties in the
flawed contract.
4.5.3 Oracle Costs
Oracle Providers furnish trustworthy off-chain information required for decisions in execution of
Smart Contracts. For example, a smart contract decision may be contingent on the prime rate in
the United States, or the spot market price of West Texas Intermediate crude oil. Oracle Providers
may demand cryptocurrency payment for their off-chain information.
4.5.4 Secure Execution Costs
Assuring trustworthy execution of Smart Contracts and storage of Blockchain-based data
requires having enough independent Validator nodes that collusion is infeasible. Duplication of
work resulting from parallel execution by a sufficiently large pool to demonstrate consensus across
a pool of independent Validators is obviously more costly than relying on execution by a single,
trusted actor.
A 51-percent attack can occur when a single bad actor or collusion of actors gains majority
control of a Blockchain network and thus can undo actual transactions, create false transactions
and otherwise alter the Blockchain. Secure Execution Costs cover the expense of making a 51-
percent attack infeasible on a Blockchain.
4.5.5 Smart Contract Diligence Costs
Transacting parties should perform appropriate diligence to assure that no bugs or fraudulent
features are included before agreeing to a smart contract. Maintaining capability to review smart
contracts and performing appropriate diligence accrues costs. For example, an independent auditor
can be hired to verify that a smart contract adheres to the written Smart Contract Specification and
follows applicable best practices.
4.6 Smart Contract as AI
Practical web3 solutions will use Smart Contracts to encode logic that automates decisions, so
coordination, collaboration, cooperation, and exchange of value occurs without direct human
supervision. Defects (a.k.a., bugs) in Smart Contracts, Contractual Incompleteness and other
factors will occassionally produce unexpected and/or erroneous results, so an appropriate Ethical
System Model should be chosen to minimize the risk of harm.
The European Commission’s high level experts group stipulated ‘artificial intelligence (AI) refers
to systems that display intelligent behavior by analyzing their environment and taking actions – with
some degree of autonomy – to achieve specific goals’ (20). Other jurisdictions use similar
Practical Web3 Solution Considerations
Page 37
definitions of AI. While Smart Contracts don’t incorporate fancy technologies like machine learning,
they aspire to execute with no human oversight by relying exclusively on on-chain data read directly
by the DApp and off-chain data reported by Oracles. Thus Regulators could argue (as shown in
Figure 15) that Smart Contracts should be covered by AI regulations:
Figure 15 Smart Contract as an AI System (underlay from (20))
1) Off-chain environment is perceived by smart contracts via Oracles.
2) On-chain data, like balances in crypto wallets, is directly perceived by smart contracts.
3) Simple reasoning, information processing and decision making is what smart contracts do.
Although engineers would hardly consider the simple logic executed by smart contracts to
be AI-level reasoning, smart contracts routinely facilitate commercial transactions that have
material consequences for real world actors in an automated fashion.
4) Off-chain actions can be triggered by executing commands from a smart contract, like
requesting a Resource Provider to provision a service element on behalf of a solution User.
5) On-chain actions, like transferring crypto coins from one crypto wallet to another, are
directly executed by smart contracts.
Decentralized Apps
(a.k.a., smart contracts)
Practical Web3 Solution Considerations
Page 38
Automated execution potentially challenges the human oversight expectations of the EC’s
trustworthy AI guidelines: ‘human oversight helps ensuring that an AI system does not undermine
human autonomy or causes other adverse effects’ (21). Section 13.2 Ethical System Model of
chapter 13 Solution Trustworthiness methodically applies
Ethics Guidelines for Trustworthy
Artificial Intelligence
(21) to practical web3 solutions, including the smart contracts that underpin
those solutions.
Practical Web3 Solution Considerations
Page 39
5 Oracles
Chapter Objective: review Types of Blockchain Oracles, Oracle Design Patterns, Oracles and the
Fundamental Problem of Smart Contracts and Legal Concerns with Oracles.
commonly refers to a person (such as a priestess of ancient Greece) through whom a
deity is believed to speak or a person giving wise or authoritative decisions or opinions14. An oracle
in the context of web3 is a ‘service that updates a distributed ledger using data from outside of a
DLT system. DLT oracles can be used by smart contracts to access data from sources external to
the DLT system’ (5).
Figure 16 Oracles in Web3 Solutions
Figure 16 visualizes Oracles in Web3 Solutions. Oracles (
in Figure 16) bridge the on-chain world
of Smart Contracts (
in Figure 16) with off-chain world inhabited by humans and physical artifacts
in Figure 16).
oracles post information about the real world onto the solution’s
Blockchain (
in Figure 16) to provide input for execution of Smart Contracts. For example:
reporting ambient temperature and humidity; reporting the winner of a sporting event; reporting
market or financial data; reading barcode or RFID tag; or reporting winner of a court case.
oracles trigger real-world actions ordered by Smart Contracts, like opening an electronic
door lock.
14 retrieved 2023-01-13.
Web3 Elements
Real (off-chain) World
Blockchains & Distributed Ledger Technologies
Smart Contracts
Digital Assets
Practical Web3 Solution Considerations
Page 40
This chapter is organized as follows:
Oracles and the Fundamental Problem of Smart Contracts (section 5.1)
Types of Blockchain Oracles (section 5.2)
Oracle Design Patterns (section 5.3)
Legal Concerns with Oracles (section 5.4)
5.1 Oracles and the Fundamental Problem of Smart Contracts
Smart Contracts transparently execute Decentralized Applications (DApps) code based on data
recorded on the solution’s Blockchain. Consensus mechanisms assure reliable execution of the
code and integrity of data recorded on the solution’s Blockchain, but how does one know that the
input data recorded on the blockchain accurately reflects reality? And if the smart contract orders
some off-chain action, like unlocking an electronically controlled door, then how does one assure
that the action is executed? Inbound and outbound Oracles solve these two fundamental
5.2 Types of Blockchain Oracles
Oracles are usefully classified across three dimensions:
1) Direction (section 5.2.1)
2) Source (section 5.2.2)
3) Trust Model (5.2.3)
5.2.1 Direction
Oracles are either:
which post data to the solution’s Blockchain, which reflects the state of off-chain
reality, like reading an environmental sensor or reporting market prices.
, which triggers some off-chain action ordered by execution of a smart
contract, like unlocking an electronically controlled gate.
5.2.2 Source
The source of input data or effector of off-chain actions can be either:
based, like reading a physical temperature sensor or barcode scanner.
based, like reading stock market or commodity pricing data over the internet.
based, like asking a human to report ground truth reality or take actions.
Practical Web3 Solution Considerations
Page 41
5.2.3 Trust Model
Oracles must be trusted to accurately report off-chain reality and/or to faithfully execute
requested off-chain actions. Technically, oracles can be:
, like having a single physical temperature sensor in a room or relying on one
source of data on the internet. Centralized oracles require that actors explicitly trust the
oracle service provider.
, like having multiple physical temperature sensors in the room, or relying
on multiple sources of data on the internet; for example, in our Sample Web3 Solution:
Ride Hailing how RiderCo is the oracle for Alice’s location and DriverCo is the oracle for
Bob’s location. Decentralized oracle arrangements require achieving consensus of off-
chain reality when oracles may report different views of truth.
Engaging multiple oracles in a decentralized arrangement is inherently more expensive than
relying on a single centralized oracle for any single input or output. Properly aligning incentives of
the beneficial owner of an oracle can make centralized oracle arrangements sufficient trustworthy
for use in practical solutions. Ideally, the beneficial owner of a centralized oracle is independent of
counterparties in relevant Smart Contracts, so they do not have conflicts of interest that could
incentivize them to shade their reporting of truth. Independent oracles must somehow be paid for
their service, so one must assure that their business model will not bias their reporting of truth.
5.3 Oracle Design Patterns
Typical design patterns for oracles are:
, like requesting that the current temperature in a room be posted to
the blockchain.
, like having the ambient temperature of a room be posted on the
blockchain every 10 minutes, so Smart Contracts can monitor environmental conditions
and trigger appropriate actions.
Immediate Action
, like ordering an electronically controlled door to open.
5.4 Legal Concerns with Oracles
Smart Contracts codify agreements --- perhaps legally binding agreements -- between parties
via software. Oracle service providers are generally third parties who are independent of parties to
the target smart contract. Inevitably, oracles are subject to failure, malfunction, security attack and
other events that render their input stale or otherwise faulty, or their output impotent, incorrect, or
perhaps even harmful (22).
Practical Web3 Solution Considerations
Page 42
So, what happens when an agreement codified in a smart contract malfunctions because:
1) Input to a smart contract from an inbound oracle does not reflect off-chain reality, so
agreement execution is faulty, or
2) Output ordered by a smart contract is improperly executed by an outbound oracle.
Clarifying liability for damages as well as accountability for root cause analysis and corrective
actions is important to bolster Solution Trustworthiness.
Practical Web3 Solution Considerations
Page 43
6 Tokens
Chapter Objective: considers Tokens, Tokenization, Benefits of Asset Tokenization, Money,
Cryptocurrency and Stablecoins.
is ‘an item, thing or entity that has potential or actual value to an organization’ (23). In
the context of web3 a
is a ‘digital asset that represents a collection of entitlements’ (5). As
shown in Figure 17, token enabled digital assets (
in Figure 17) include: native tokens like $ETH for
Ethereum; Stablecoin; and Non-Fungible Tokens (NFTs). Those token enabled digital assets (
Figure 17) are based on Smart Contracts (
in Figure 17) which are underpinned by a solution
Blockchain (
in Figure 17).
Figure 17 Tokens in Web3 Solutions
This chapter is organized as follows:
Token (section 6.1)
Tokenization (section 6.2)
Benefits of Asset Tokenization (section 6.3)
Money, Cryptocurrency and Stablecoins (section 6.4)
Web3 Elements
Real (off-chain) World
Blockchains & Distributed Ledger Technologies
Smart Contracts
Digital Assets
Practical Web3 Solution Considerations
Page 44
6.1 Token
Token is commonly defined as ‘a piece resembling a coin issued for use (as for fare on a bus) by a
particular group on specified terms’ 15. Figure 18 shows a well-known, pre-digital, fungible token.
Points in loyalty programs like airline miles are an example of pre-web3 fungible digital tokens.
Figure 18 A Pre-Digital Token
Tokens are commonly used for the following purposes:
Utility tokens are ‘used by its owner to receive access to goods or services’ (5), like the
traditional token of Figure 18 that paid for one ride on the New York subway.
Governance tokens entitle the token holder to vote on governance decisions, like owning
shares of common stock entitles an investor to participate in the board of directors’
election for the firm.
Ownership tokens reflect ownership of some physical or digital asset, like a valet parking
claim check reflects your ownership claim on a particular vehicle in the parking lot.
Access tokens grant you access to some service or resource, like an airline boarding pass
grants you access to a particular seat on a flight.
Credential tokens include things like the plastic card many readers carry in their wallet
that represents their license to drive a motor vehicle, or the framed documents many
people prominently display attesting their graduation from a prestigious school or their
professional license.
15 retrieved 2022-06-01.
Practical Web3 Solution Considerations
Page 45
6.2 Tokenization
links a physical asset or virtual asset to a cryptographic token stored on a
blockchain (24). The cryptographic token represents ownership, custody, or permission for some
underlying physical or virtual asset. Crypto tokens rely on Smart Contracts to automate transaction
workflows and on some underlying Blockchain for storage and execution of those Smart Contracts.
In particular, Smart Contracts can efficiently manipulate and transfer cryptographic tokens native to
the blockchain hosting the smart contract, so token-related workflows can be fully digitalized.
There are two types of cryptographic tokens:
Fungible Tokens (section 6.2.1)
Non-Fungible Tokens (NFTs) (section 6.2.2)
6.2.1 Fungible Tokens
means ‘being something (such as money or a commodity) of such a nature that one
part or quantity may be replaced by another equal part or quantity in paying a debt or settling an
account’16. For example, every US dollar is functionally identical, or fungible, to every other US
dollar. Note that although each US dollar note bears a unique serial number, each is fungible with
any other US dollar. Similarly, Bitcoins are Fungible Tokens in that each Bitcoin is functionally
identical to every other Bitcoin.
ERC-20 defines fungible cryptographic tokens for the Ethereum blockchain.
6.2.2 Non-Fungible Tokens (NFTs)
Non-Fungible Tokens (NFTs) are cryptographic tokens representing ownership of non-fungible
digital assets, like a particular Bored Ape Yacht Club digital collectable. Each of the 10,000 Bored
Ape Yacht Club digital collectables living on the Ethereum blockchain are unique, so the tokens
representing these digital collectables are
fungible tokens that represent a digital certificate of
authenticity meaning that the NFT owner is the authentic owner of the unique asset referenced by
the NFT.
Crucially, Non-Fungible Tokens (NFTs) are engineered to be tradeable so the owner of an NFT can
securely sell ownership or transfer ownership rights to another party. Beyond representing
ownership of digital novelties like Bored Ape Yacht Club collectables, Non-Fungible Tokens (NFTs)
can be used to reflect ownership of (25):
o Digital artwork
o Music
o Photographs
o Virtual goods, like virtual sneakers for your metaverse avatar to wear
16 retrieved 2022-06-02.
Practical Web3 Solution Considerations
Page 46
o Event tickets
o Membership passes
o Domain names
The value of an NFT is based on (26):
1) Scarcity because each NFT is unique.
2) Ownership rights to a referenced asset should permit the NFT owner to grant use of the
asset to some, deny use of the asset to others and resell ownership of the NFT.
3) Breadth of domains supporting and recognizing NFT ownership. An NFT for a virtual asset
that is usable on a single multiverse platform is less valuable than an NFT that is usable on
most multiverse platforms.
6.2.3 Soul Bound Tokens
Assets like educational credentials, awards, professional certifications, and licenses are bound to
individual actors. For example, you can loan your automobile (a
asset) to your cousin to
drive to a job interview, but you cannot loan your cousin your college diploma and professional
license (
assets) to use in the interview. Soul bound tokens refer to Non-Fungible Tokens
(NFTs) that are explicitly issued to an identity (i.e.,
soul bound
) so they cannot be sold, loaned, or
otherwise transferred to others (27). Soul bound Non-Fungible Tokens (NFTs) are useful for
o Academic achievements, grades, and credentials
o Proof of attendance or participation
o Certifications
o Awards
6.3 Benefits of Asset Tokenization
Blockchain-based cryptographic tokenization promises several benefits compared to traditional
token schemes:
Reduced transaction costs of developing, managing, and trading tokenized assets.
Shorten settlement time because Transactions are digitally committed in minutes or
seconds rather than manually processed in days.
Increased liquidity via faster and easier trading of cryptographic tokens.
Narrower, more precise ownership rights - digitalization and Smart Contracts enable rights
and responsibilities of token ownership to be unbundled and re-bundled in novel ways that
are more attractive to prospective buyers.
Practical Web3 Solution Considerations
Page 47
Greater transparency and Confidence – blockchain-based Transactions make it easier for
actors to verify the true owner of assets, which reduces risk of fraud.
Simplified Fractional Ownership of Assets – Many assets, like corporations, vacation homes,
and yachts, are large, lumpy, and long-lived, so fractionalizing ownership makes them more
attractive, affordable, and liquid for a larger pool of prospective owners. For example, it is
far more convenient to buy or sell fractional ownership shares of a company in the form of
common stock shares than it is to buy or sell the entire company. Tokenization makes
cooperative, time-shared and other multiparty fractional ownership models practical for
many classes of assets.
6.4 Money, Cryptocurrency and Stablecoins
Money has three functions:
1. Store of value, so the value of a quantity of money in an actor’s wallet does not fluctuate.
Fiat currencies like the US dollar and Euro are a sufficiently stable store of value that
investors happily buy long-dated bonds paying modest interest rates. Floating
cryptocurrencies are notoriously volatile, which makes them popular with speculators, but
not with investors interested in a stable store of value.
2. Unit of account, so that prices for inputs consumed and outputs sold can be tracked and
quantitatively measured. Businesses generally maintain accounts and report their financials
in the fiat currency of the jurisdiction where they are incorporated because most of their
revenue and expense are settled in that jurisdiction’s fiat currency. Firms doing business in
cryptocurrency must account for their cryptocurrency revenue and expenses.
3. Medium of exchange, so that inputs can be efficiently purchased from suppliers and sold to
customers. Cryptocurrencies are digital representations of money that can efficiently be
transferred by smart contracts executing on the same blockchain, so cryptocurrency can be
a good medium of exchange. Paolo identifies four key features for a payment network to
support economic exchange (28):
a. Speed- Blockchain cycle times limit the speed to cryptocurrency transfers, but they
can be faster traditional payment rails like US Automated Clearing House (ACH) or
b. Payer control – smart contracts settling cryptocurrency payments can potentially
provide sophisticated payer controls.
c. Security – robust security mechanisms protect traditional payment rails like ACH, Fed
wire and Swift. Cryptocurrency exchanges routinely collapse (e.g., FTX
Practical Web3 Solution Considerations
Page 48
cryptocurrency exchange filed for bankruptcy on November 11th, 2022), so security
remains problematic.
d. Universality – most people and virtually all businesses in developed countries have a
bank account which is accessible via traditional payment rails. Few businesses and
people have cryptocurrency accounts today. Without universality, businesses, and
consumers generally fallback to familiar payment rails like VISA and ACH.
Note that a currency doesn’t have to have universality or all other features of money to be
useful. For example, although casino chips are only accepted inside the casino that issued them,
chips are very convenient when betting and the casino guarantees to buy and sell chips on-demand
at face value. This means that gamblers can buy $1000 of chips when they enter a casino, and the
casino will happily exchange any chips they have left when they leave for dollars.
6.4.1 Stablecoin
are ‘cryptocurrencies where the price is designed to be pegged to a reference asset.
The reference asset may be fiat money, exchange-traded commodities (such as precious metals or
industrial metals), or a cryptocurrency’17. Pegging stablecoin to a jurisdiction’s unit of account (e.g.,
US dollars for businesses operating the US) elegantly addresses the unit of account function of
money. Structuring the stablecoin so that asset value does not fluctuate makes stablecoin a
reliable store of value.
Stablecoin tokens can be issued and used safely when a trustworthy (e.g., centralized) actor
guarantees liquidity and value stability, like how the Bellagio Casino in Las Vegas guarantees to
exchange their physical tokens on-demand for US Dollars at face value. Unfortunately, not all
stablecoin asset pegging mechanisms and guarantors are as trustworthy as the Bellagio Casino.
17 retrieved 2022-10-26.
Practical Web3 Solution Considerations
Page 49
7 Decentralized Solution Ecosystem
Chapter Objective: introduces roles and motivations of primary actors in a decentralized web3
solution ecosystem.
This chapter sketches general Roles of Decentralized Solution Ecosystem actors that can apply
to many Likely Web3 Problem Domains in the following sections:
Actor Motivation (section 7.1)
Roles (section 7.2)
Value Capture Options for Decentralized Web3 Actors (section 7.3)
Web3 Actors (section 7.4)
7.1 Actor Motivation
Actors voluntarily engage with a Decentralized Solution Ecosystem to achieve some valuable
in Figure 19), which is often either to:
Get paid, like driver Bob from Sample Web3 Solution: Ride Hailing who engages to earn
Receive something of value, like rider Alice from Sample Web3 Solution: Ride Hailing who
engages to be transported to a destination.
Figure 19 visualizes the desired outcome in the context of the actor’s value proposition:
Figure 19 Actor Motivation and Value Proposition
how solution
supports the
actor’s critical
business goals
explain how
addresses the
actor’s need
from PMO and
Actors voluntarily engage
with a solution to achieve
some outcome
actor gets paid
receives something of value
value the actor
expects to
achieves by
engaging with
1 32 4
Practical Web3 Solution Considerations
Page 50
1) Need – a successful solution addresses the actors’ critical business need. Note that the
same solution can address different needs for different actors. For example, rider Alice
in our Sample Web3 Solution: Ride Hailing because she needs to be transported to
another location and driver Bob uses Sample Web3 Solution: Ride Hailing because he
wants to earn money in his spare time.
2) Assertion – explains the solution that addresses actors’ needs. For example, our Sample
Web3 Solution: Ride Hailing might assert to riders that it is a more socially responsible
version of Uber and assert to drivers that they can set their own fares.
3) Outcome – is the specific benefit each actor expects to achieve from engaging with the
4) Distinction – differentiates the target solution from present mode of operation (PMO)
and plausible alternatives. For example, what differentiates our Sample Web3 Solution:
Ride Hailing from Uber or calling a taxi?
One should explicitly articulate the value proposition for each of the primary actors when
considering a Decentralized Solution Ecosystem concept.
7.2 Roles
Figure 20 visualizes Primary Roles in a Decentralized Solution Ecosystem:
Figure 20 Primary Roles in a Decentralized Solution Ecosystem
Decentralized Solution
Buyers Sellers
Validators Validator 1
Service Provider
Sell SideBuy Side
Web3 Style Interactions
Web3 Style Interactions
Web2 Style Interactions Other Actors
Validator 2 Validator N
Alice RiderCo DriverCo
Practical Web3 Solution Considerations
Page 51
1) User (section 7.2.1)
2) Resource Provider (section7.2.2)
3) Service Provider (section 7.2.3)
4) Validator (section 7.2.4)
5) Leader (section 7.2.5)
6) Oracle Provider (section 7.2.6)
7) Power (Web3) User (section 7.2.7)
8) Power (Web3) Provider (section 7.2.8)
9) Regulator (section 7.2.9)
Actors like firms or natural persons can play one or more roles in a Decentralized Solution
Ecosystem, like a prosumer who acts as both User and Resource Provider, or both Power (Web3)
User and Power (Web3) Provider.
7.2.1 User
Users are organizations or natural persons who engage with a Decentralized Solution Ecosystem
via a Service Provider to create or consume value rather than engaging directly with the Blockchain.
Users who can be parties in Smart Contracts. Driver Alice and rider Bob are two Users of our
Sample Web3 Solution: Ride Hailing.
Note that sophisticated Users could accept the complexity of directly engaging with the
Blockchain rather than relying on a Service Provider and act as Power (Web3) Users.
7.2.2 Resource Provider
Resource Providers are corporations or natural persons who offer resources or services to a
Decentralized Solution Ecosystem via a Service Provider. Sophisticated Resource Providers can
accept the complexity of engaging directly with the Blockchain rather than relying on a Service
Provider and act as Power (Web3) Providers.
7.2.3 Service Provider
Service Providers operate applications that post Blockchain Transactions with a Validator to
execute Smart Contracts, and access Blockchain data on behalf of a User or Resource Provider. In
particular, Service Providers methodically execute the Agreement Lifecycle, such as searching for
counterparties on behalf of a User, formally assembling smart contracts and initiating execution of
Transactions and Smart Contracts. For our Sample Web3 Solution: Ride Hailing, RiderCo is a buy-
side Service Provider supporting User Alice, and DriverCo is a sell-side Service Provider supporting
Resource Provider Bob.
Note that rather than acting primarily as a trusted third party intermediary like a notary, Service
Providers compete to make it efficient, effective and effortless for Users and Resource Providers to
engage with a decentralized web3 solution, like by maintaining wallets for Users’ tokens and
Practical Web3 Solution Considerations
Page 52
7.2.4 Validator
Validators operate nodes hosting the Blockchain and Smart Contracts/Decentralized Applications
(DApps) execution environments that participate in distributed Consensus. Any actors may serve as
a Validator of permissionless Blockchains, but explicit approval by the Leader may be required for
an actor to become a Validator of permissioned Blockchains.
7.2.5 Leader
Leader is the keystone firm or organization that kickstarts a decentralized web3 solution, like the
Ethereum Foundation or the Filecoin Foundation or the Helium Foundation. Core Leader
Responsibilities include:
1) Define rules, structure, and governance of actors’ engagement with the solution.
2) Oversee the creation, operation, and evolution of the solution.
3) Engineer and kickstart sustainable, positive Network Effects.
4) Assuring System Trustworthiness so actors are comfortable interacting via the solution.
Chapter 10 considers Leadership and chapter 11 considers Governance.
7.2.6 Oracle Provider
Oracle Providers offer as trusted sources of off-chain data via their Oracles to support execution
of Smart Contracts. Input from Oracle Providers can trigger Smart Contracts to take actions like
executing financial transactions or sending commands to smart devices (19).
7.2.7 Power (Web3) User
Power (Web3) Users are corporations or natural persons who consume services or resources
offered by Resource Providers or Power (Web3) Providers into valuable use cases, which they
consume. Power (Web3) Users directly engage via web3 protocols instead of using a buy-side
Service Provider, and thus must search for counterparties, organize their Smart Contracts, manage
their own crypto wallet and other features routinely provided by buy-side Service Providers.
7.2.8 Power (Web3) Provider
Power (Web3) Providers are corporations or natural persons who offer resources or services to
Users (via their buy-side Service Providers) and Power (Web3) Users directly via web3 protocols.
Practical Web3 Solution Considerations
Page 53
7.2.9 Regulator
Any web3 solution that might harm a natural person or corporation may attract the attention of
Regulators. Regulators often concern themselves with privacy law, competition law, national
security, labor law, tax law and other regulatory topics. Different jurisdictions have different laws,
regulations and Regulators. Users, Resource Providers, Service Providers and other Decentralized
Solution Ecosystem actors will want assurances that engaging with the solution will not draw
unfavorable attention and actions of applicable Regulators.
Chapter 16 covers Regulatory and Compliance Considerations.
7.3 Value Capture Options for Decentralized Web3 Actors
All actors voluntarily engage with an ecosystem because they capture enough value to make it
worthwhile. Figure 21 illustrates options for value captured by decentralized web3 actors across
the Temporal Phases of an Agreement:
Figure 21 Value Capture Options across Transaction Time
1) Early Phase – firms can sell software development to a Leader (e.g., develop and integrate
core web3 solution software) as well as training, consulting, application software
development and integration to application Service Providers (e.g., RiderCo, DriverCo) and
end Users of application Service Provider’ offerings.
2) Search Phase – firms can offer search algorithms, tools, or as-a-service offerings to help
actors more efficiently find decentralized counterparties. For example, RiderCo sells
to riders and DriverCo sells
rider search
to drivers. Service Providers can monetize
their search offerings via subscription, or a cryptocurrency charge on accepted Smart
Contracts for rides or via other mechanisms. Oracle Providers and data brokers can provide
Ex Ante Ex Post
For counterparty
(i.e., smart
node and
1 2 3 4 5 6
Practical Web3 Solution Considerations
Page 54
information, which is used by those Service Providers for search (e.g., a reputational service
providing driver ratings, or a driver information system verifying that the driver has
adequate insurance coverage). Technology providers can provide mechanisms to cleverly
search and sort potential rides for riders or fares for drivers.
3) Design Agreement PhaseLeaders are likely to write the fundamental Smart Contracts
used on the blockchain, but those fundamental Smart Contracts might be wrapped in
higher-level contracts to deliver higher value to Users. For example, a buy-side Service
Provider for our Sample Web3 Solution: Ride Hailing may appeal to ecologically conscious
riders by including an appropriate carbon offset transaction in the Smart Contracts for their
rides so their travel is carbon neutral.
4) Agreement Event – firms can facilitate committing agreement transactions to the blockchain
(e.g., RiderCo posting agreed ride hailing Smart Contracts as a buy-side Service Provider).
Firms can host blockchain and validate transactions as a Validator.
5) Monitor Phase – firms can offer Oracles to support execution of Smart Contracts. Quality
attributes gathered during the monitor phase can be gathered, which can be rendered into
Indicators and Trust Cues that buy-side Service Providers and other actors might pay for.
6) Settle Agreement Phase – while execution of Smart Contracts automatically settles
payments for successfully executed agreements, less than 100% successful agreement
execution may require additional services, like arbitration, collection services or other off-
chain enforcement services.
7.4 Web3 Actors
As shown by
in Figure 22, web3 protocols are used for interactions between the following
actors: Service Providers, Validators, Oracle Providers, Power (Web3) Users and Power (Web3)
Providers. Transactions within the web3 protocol perimeter are often settled with the
cryptocurrency native to the underlying blockchain, like paying Validators and the Leader applicable
transaction processing fees.
Practical Web3 Solution Considerations
Page 55
Figure 22 Actor Interaction Protocols
As shown by
in Figure 22, Users and Resource Providers engage with the Decentralized
Solution Ecosystem via Service Providers using web2 interactions, like an app on their smartphone.
This means that a User or Resource Provider engages with a decentralized web3 solution without
using web3 protocols themselves.
Decentralized Solution
Buyers Sellers
User Resource
Web2 Style Interactions
Web3 Protocol Perimeter
Validators Validator 1 Validator 2 Validator N
Service Provider
Sell SideBuy Side
Practical Web3 Solution Considerations
Page 56
8 Token Economics
Chapter Objective: considers the Value Exchange Model that motivates Decentralized Solution
Ecosystem actors to willingly engage with a web3 solution.
This chapter considers the
of Figure 23) that each Decentralized Solution Ecosystem
actor willingly exchanges for the desired
of Figure 23) promised by the solution. Value
propositions, desired outcomes and Actor Motivation were considered in chapter 7 Decentralized
Solution Ecosystem.
Figure 23 Practical Web3 Solution Token Economics Model
While traditional economic exchanges rely on barter or fiat currency payment between actors,
smart-contract-based Tokens are a different way to exchange value between actors to facilitate
cooperation and engagement. Utility (e.g., payment) tokens, governance tokens, ownership tokens,
access tokens and credential tokens offer new ways to bundle, quantify and exchange values
between Decentralized Solution Ecosystem actors. Establishing a stable and fair set of rules and
mechanisms governing the lifecycle of solutions tokens is essential to a successful and sustainable
web3 solution.
This chapter is organized as follows:
Reimagining Ecosystem Leadership (section 8.1)
how solution
supports the
actor’s critical
business goals
explain how
addresses the
actor’s need
from PMO and
value the actor
expects to
achieves by
engaging with
Model 1
Token economics considers what
actors willingly exchange to
receive the solution’s
desired outcome
Practical Web3 Solution Considerations