diff --git a/src/papers/smart-token-paper.md b/src/papers/smart-token-paper.md
index e8d178d..adc4d56 100644
--- a/src/papers/smart-token-paper.md
+++ b/src/papers/smart-token-paper.md
@@ -9,7 +9,7 @@ abstract: |
 
 ## The Web's Foundational Model
 
-When Tim Berners-Lee and his team developed the foundational concepts of the Web, they conceptualized 'sites' as its primary building blocks, akin to physically exploring different sites in the digital world. This seemingly intuitive approach, however, was not a given, as prior Internet protocols did not revolve around the concept of sites. Consider USENET: it organises and manages information by topic, making it irrelevant which site or even which planet the information originates from under that topic.
+When Tim Berners-Lee and his team developed the foundational concepts of the Web, they conceptualised 'sites' as its primary building blocks, akin to physically exploring different sites in the digital world. This seemingly intuitive approach, however, was not a given, as prior Internet protocols did not revolve around the concept of sites. Consider USENET: it organises and manages information by topic, making it irrelevant which site or even which planet the information originates from under that topic.
 
 The Web embraced a site-centric model: a site has a single origin, is inherently competitive, forms an ecosystem through hyperlinks, and evolves as a platform rather than a static product. This model complemented the revolutionary capabilities introduced by HTML, contributing to the Web's rapid adoption and eventual dominance as an Internet application. Even in the mobile Internet era, the foundational model of 'sites' persisted[^mobile].
 
@@ -17,7 +17,7 @@ The Web embraced a site-centric model: a site has a single origin, is inherently
 
 Berners-Lee and other early web pioneers didn't adopt the "site" concept merely for its potential evolutionary power. Instead, the Web's design was heavily influenced by a prevailing metaphor of that era — the library model, which likened the Internet to a vast library. This metaphor transposed a library's concept—a collection of books—to the digital realm, turning the Internet into a collection of sites. Just as a book references pages, the Web adopted "web pages." This framework led to structuring the Internet around origins (sites) instead of topics (as in USENET) or functionality (as in FTP). Hyperlinks became akin to library indexes, but site owners controlled these links, creating a self-referential mega-book that spanned the entire library[@tim1994].
 
-Structuring the Web around origins rather than topics (like USENET) or functionality (like BitTorrent) had profound implications. It led to websites' single-origin design, reminiscent of how books have specific authors. Today, multi-domain sites are rare. **This site-origin model imbued each website with a sense of credibility anchored in its source.** This subtle, yet pivotal decision laid the groundwork for a more centralised Web, inadvertently setting the stage for *the emergence of focal points* in the web's trust landscape, a phenomenon we explore further in the subsequent sections.
+Structuring the Web around origins rather than topics (like USENET) or functionality (like BitTorrent) had profound implications. It led to websites' single-origin design, reminiscent of how books have specific authors. Today, multi-domain sites are rare. This site-origin model imbued each website with a sense of credibility anchored in its source. This subtle, yet pivotal decision laid the groundwork for a more centralised Web, inadvertently setting the stage for the emergence of anchor points in the web's trust landscape, a phenomenon we explore further in the subsequent sections.
 
 ## The Shift from Information to Applications
 
@@ -277,21 +277,29 @@ In the absence of a platform, tokens need to rely on standards and composable in
 
 Given that a token can enable multiple web applications, it often becomes a more attractive target for attacks than the website itself. The design of the token runtime must take this into account. Furthermore, to safeguard websites from generating incorrect or malicious transactions, transactions should be generated inside the Token's Runtime Environment, in response to the need of the web application it supports. For example, a car cleaning service website shouldn't have the code to generate a car-key authorisation; it should only have the code to call for such an authorisation to be generated.
 
-#### Token's User Interface
+#### Provision of Token User Interface
 
-The token's user interface is a crucial element of the token runtime code. It is essential for the token to create its own user interface to elevate the trust in the website to meet the web application's demand. The token's visual presentation should be created in a secured Token Runtime Environment. This is akin to how Metamask, a browser plugin, provides the interface between the user and a blockchain-enabled Dapp for connecting the wallet and authorising transactions. However, in the case of smart tokens, the UI needs to be specific to the token to enable its use-cases[^token-ui-examples].
+Token UI is a crucial component of the Token Runtime Environment. This environment is more than a mere backdrop for token operations; it serves as a visual trust anchor in bridging the gap between the complex functionalities of tokens and the web applications they support. This section will delve into this often overlooked aspect.
 
-[^token-ui-examples]: Say for example, if Tesla Car-Key is a smart token, users need to see Tesla taking over the process and pass authorisation to the website, similar to how Google Wallet or MetaMask takes over the process and passing the result to the website. 
+### The Critical Role of a Token's User Interface in Smart Tokens
 
-The user interface (UI) of a token is a crucial aspect of the token runtime code. It must be tailored to the token to enable its specific use-cases. For instance, the UI for a user to authorise a car-key token for a car cleaning service would be entirely different from another user - who holds a smart-flight ticket (also a smart token) - booking a connected hotel stay. Even with the same token, different use-actions necessitate different user interfaces. Providing the location through a car-key token is a simpler user interface than authorising a website to send staff to drive it. The user interface of a token is determined by the actions it can perform, which web applications depend on.
+The user interface (UI) of a token is not just a convenient tool for users to interact with tokens directly; it plays a essential role in establishing tokens as trust anchors. Traditional tokenisation frameworks have often relegated tokens to function purely as APIs, neglecting their capacity as trust anchors. This oversight arises from a failure to recognise the dual role of tokens: they provide functionality and establish trust within web applications.
 
-One argument against the use of token-specific interfaces suggests that websites tend to customise everything within their operational environment. However, the consistent visual presentation of Google Pay and Google Login across different websites of various colours and fonts demonstrates that the trust factor - users recognising a symbol of trust to carry out actions - outweighs the visual experience alone.
+To comprehend why a token's UI is instrumental in elevating the trust users place in web applications, consider how Google Login and Google Pay maintain their distinct UIs across various platforms, instead of providing just API calls and allow websites to capture user interaction. A comparison within the Ethereum ecosystem itself is also enlightening: before the popularity of Metamask, Mist - a browser wallet - was the mainstream way to access Dapps. Unlike Metamask, which prompts users to connect their wallet and execute transactions via a separate, interactable UI, Mist allowed Dapps to be directly connected to the node, providing wallet functions purely as an API. This trust model didn't work, as it placed the responsibility of trusting a website entirely on the user. Evolution sided with Metamask, and Mist no longer exists.
 
-A related argument proposes that the token interface could be supplied by a web front-end library rather than being generated by the token's secure runtime environment. This reflects a misunderstanding of the dual role of trust anchors in that they provide both function and trust. The token user interface on a website provides no more trust than the website itself, as it is entirely under the website's control. Therefore, the token-specific user interface must be generated within the token's secure runtime environment to ensure trust is maintained.
+The comparison between Mist and Metamask, along with examples of traditional trust anchors, underscore the need for a user interface. However, for Smart Tokens, the UI needs to be further tailored to the specific use-cases of each token.
 
-Therefore, the design choices for a smart token's runtime environment for serving as a trust anchor can be generalised as the following:
+For instance, a Smart Car token and a Smart Flight Ticket token would have vastly different UI requirements. The Smart Car token might require a UI that facilitates car location sharing or authorises a car cleaning service, while the Flight Ticket token would need a distinct UI for activities like booking connected hotel stays. Even within the same token, such as a Smart Car Token, the UI would differ based on the level of trust required. For instance, authorising a car cleaning service would require a different UI than proving control over the car to a hotel website. This specificity in UI design ensures that the token's interface aligns with the actions it is designed to perform, enhancing user experience and application functionality.
 
-It is a separate runtime environment from the application it supports, is event-driven and has declarative components. This design ensures that the token can serve as a trust anchor and provide the necessary functions while maintaining a high level of security.
+#### Common objections to tokens having their own user interface
+
+When the idea of Smart Tokens having their own interface was first introduced in 2019, it faced several objections. These mainly stemmed from the discomfort of entering the multi-domain web design space. As mentioned earlier in the paper, multi-domain websites are unusual, as they break the trust boundary users have associated between sites and their credibility.
+
+One common argument against token-specific interfaces is that web designers want to control every visual element of the site, considering it their turf. However, the consistency of interfaces like Google Pay and Google Login across varied website designs underscores the importance of a familiar and consistent UI for trust.
+
+Another idea accepts that a token might have its own user interface but denies it its own runtime environment. This is done by supplying the token's interface through a web front-end library. This approach overlooks the key role of trust anchors. A token's UI, when embedded in a website, offers no more trust than the website itself, as it remains under the website's control. Therefore, for a token to effectively serve as a trust anchor, its user interface must be generated within the token's own secure runtime environment.
+
+In conclusion, the design choices for a smart token's runtime environment necessitate a separate, secure space that is event-driven and includes declarative components. Such a design ensures the token can reliably serve as a trust anchor, providing necessary functions while maintaining a high level of security and enhancing the overall user experience.
 
 ### Deployment of Token Runtime Environment