Earlier in the month, Paradiso, alongside our friends and partners at Friendly Market, launched our initial version of an MPC-powered simple liquid staking derivative on Casper.

Liquid staking is a form of tokenization in which an asset that would normally be locked in stake (in this case, Casper staked as a validator) is made available in a fungible manner, with the rewards earned on the asset slowly changing the value of the representative asset while retaining the ability to be tradeable and unlocked. (more information on Liquid Staking)

Technology

Paradiso utilizes the same MPC implementation used in our bridge on Casper (a modified fork of ZenGo’s Gotham City MPC Library)

Our MPC node effectively acts as a EOA (Externally Owned Account) on Casper and stakes to Arcadia’s validator directly without needing a smart contract. You’re effectively getting the benefits of staking with a validator, without having to have your funds be locked

Token Economics

stCSPR is designed to model the Wrapped stETH architecture, where the amount of CSPR that stCSPR represents changes as staked rewards are earned.

An example of how the Wrapped Staked Casper Architecture works is as follows.

You wrap 10,000 CSPR into stCSPR

You continue to earn staking rewards with your stCSPR as if you had staked it with a Casper Validator directly.

When you unwrap your stCSPR, you receive 10,000 CSPR plus whatever your staking reward was (for example, at 8% staking returns, you would receive 66 CSPR over a month)

Risks

Many risks come with any DeFi application, and doubly so with applications built on new technology. We’ve outlined some of the known risks on our docs. Please be cautious and cognizant of capital risk when interacting with our applications as there is an inherent and substantive capital risk when interacting with smart contracts and emerging technology

Learn More

If you want to learn more about Paradiso’s stakedCSPR implementation, check our dashboard, docs, and deployed contracts!

Liquid Staking on Casper was originally published in Paradiso Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the developing landscape of decentralized finance (DeFi), complexity within DeFi protocols is always evolving and becoming more opaque. Most modern DeFi protocols introduce financial logic to systems that are often misunderstood, difficult to track, and require serious thought to keep stable and secure. While traditional smart contract security audits (including what Arcadia offers) are critical to securing protocols, economic security requires a different, more asset and state-oriented approach to analysis.

That’s where Arcadia’s economic security offering comes into play; built off the backs of concepts proposed and theorized in academia and used in practice by existing industry leaders, Arcadia has designed a thorough solution to model and assess risk amongst target protocols in both semi-isolation and within the broader cross-protocol and smart contract risk.

Arcadia’s economic security offering comes in two forms, point-in-time snapshots and continuous risk management and analysis. Point-in-time snapshots act as an initial litmus test and state analysis of inner protocol economic assumptions (i.e., in-protocol asset conversion, fixed rates), external assumptions (i.e., supported collateral types within lending markets, cross-protocol risk assumptions, price sources, and pricing logic). This allows for protocols to take a momentary look at where they stand and adapt their infrastructure to be a more hardened, risk-aware, and design-conscious system.

Continuous risk management allows us to take point-in-time learnings and known risk factors and consciously model them into a continuous tracking and notification model. Taking things like supply changes, collateral utilization rates across multiple environments, and many other metrics to help inform clients on potential advisable protocol parameters.

Risk in DeFi will always be high, but taking honest and well-thought steps to mitigate it wherever possible is imperative. We’re excited to be making economic security a primary offering of ours, and helping evolve the future of money legos. If you’re a protocol in need or are interested in speaking with us. Feel free to reach out to audits@arcadia.agency

Securing DeFi with Arcadia’s Economic Security Offering was originally published in The Arcadia Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

In a recent incident, the decentralized lending and borrowing platform, Themis Protocol, fell victim to a flash loan exploit on the Arbitrum network. Exploiting a flawed oracle, the exploiter manipulated the B-wstETH-WETH-Stable-gauge price, resulting in significant gains for themselves. This article delves into the details of the exploit, the aftermath, and the steps taken by Themis to address the situation.

The flash loan transaction targeted Themis Protocol on the Arbitrum network. By depositing 54.6 B-wstETH-WETH-Stable-gauge (obtained by joining the balancer pool with 55 WETH), the exploiter borrowed 317 WETH. This malicious maneuver effectively drained the lending funds, allowing the exploiter to profit approximately $370,000.

Flawed Oracle Exploitation

The underlying cause of the hack was a flaw within the protocol’s oracle system. The exploiter manipulated the B-wstETH-WETH-Stable-gauge price, artificially inflating it to their advantage. This exploitation enabled them to execute the flash loan exploit successfully, compromising the integrity of the lending and borrowing platform.

Exploit Illustration

For a clearer understanding of the exploit, one can examine the specific transaction (https://arbiscan.io/tx/0xff368294ccb3cd6e7e263526b5c820b22dea2b2fd8617119ba5c3ab8417403d8).

The transaction details shed light on the key steps involved in the exploit, providing insights into the nature of the vulnerability and the exploiter’s actions.

What Happened Next

After gaining access to the funds, the exploiter cross-chained them using Stargate Finance. The funds were converted into ETH and subsequently parked at the address: 0xdb73eb484e7dea3785520d750eabef50a9b9ab33.

Themis’ Response and Future Plans

Themis Protocol promptly addressed the exploit and took measures to mitigate the impact on its users. In a notable announcement, Themis declared that it would absorb the bad debt resulting from the exploit by adding the lost liquidity back into the protocol. This action was taken to ensure the uninterrupted operation of the platform and to safeguard user funds.

Additionally, Themis emphasized the importance of conducting thorough audits of the protocol to guarantee its safety and security. The team pledged to work closely with auditors to review the system, aiming to provide a specific timeline for reopening liquidity once the audit process is completed.

We commend the team at Themis for going above and beyond by absorbing the bad debt and committing to further audits. Building DeFi is hard, and Themis has shown resiliency and a high ethical standard by rolling with the punches and mitigating losses for their investors.

Compensation for Affected Users

Recognizing the impact on affected users, Themis announced a unique compensation plan for those who still believe in the potential of the platform. The details of this compensation plan were not disclosed in the initial notice, but it shows Themis’ commitment to addressing the concerns and restoring trust among its user base.

Conclusion

The recent exploit on Themis Protocol’s lending and borrowing platform serves as a reminder of the ongoing challenges in maintaining the security and resilience of decentralized financial systems. The incident highlights the critical importance of robust oracle systems, thorough audits, and proactive measures to mitigate potential vulnerabilities. Themis Protocol’s response, including absorbing the bad debt and implementing compensation plans, demonstrates their commitment to user safety and recovery. As the platform undergoes auditing and implements necessary improvements, it aims to regain users’ trust and continue its mission of providing a secure and efficient peer-to-pool lending and borrowing experience.

If you are a blockchain project, DeFi platform, or DApp developer seeking to enhance the security and resilience of your smart contracts, consider partnering with Arcadia. As a leading smart contract security and product development company (https://arcadia.agency), Arcadia offers comprehensive security audits and code reviews to mitigate vulnerabilities and prevent potential exploits. With their team of experienced security experts and thorough testing methodologies, Arcadia can help fortify your project against potential risks. Don’t leave your project’s security to chance — reach out to Arcadia today to ensure the robustness of your smart contracts and maintain user trust.

Themis Protocol Exploited: Flawed Oracle and Flashloan Causes Losses was originally published in The Arcadia Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

In this article, we take a closer look at Binance’s Threshold Signature Scheme (TSS) implementation, which is based on the original paper “Fast Multiparty Threshold ECDSA with Fast Trustless Setup,” for short, GG18 [1].

In this article, we will concisely explain how Binance’s Threshold Signature Scheme (TSS) works. Additionally, we will delve into its application and current adoption status. To gain a comprehensive understanding, we will assess the security concerns of previous versions and explore recent vulnerabilities discovered in similar TSS implementations, particularly with regard to Binance’s TSS. Finally, we will conclude by offering essential recommendations for safely utilizing Binance’s TSS implementation.

What’s the Threshold signature scheme (TSS)?

Threshold Signature Scheme (TSS) revolutionizes cryptographic digital signatures by enabling a subset of t+1 parties from an independent group of n participants to collaboratively generate a digital signature for a message without exposing their private keys to either group members or external entities. This innovative approach maintains signer privacy while allowing verification using conventional centralized signature schemes. TSS has garnered significant attention in the blockchain realm due to its potential for applications such as secure key management, multiparty wallets, and digital asset custody solutions.

Most recent forms and popular implementations of Threshold Signature Schemes (TSS) rely on the elliptic curve digital signature algorithm (ECDSA). Elliptic curve cryptography has gained traction due to its ability to generate smaller key sizes in comparison to non-EC cryptographic systems. The efficiency and compactness of ECDSA have led to its widespread adoption in the world of cryptocurrencies, including prominent examples like Bitcoin.

GG18 [1] stands out as the leading ECDSA-based Threshold Signature Scheme (TSS), renowned for its remarkable reduction in communication complexity among signers, surpassing other similar schemes [8, 9]. This distinct advantage has facilitated the development of practical implementations in various programming languages like Go and Rust. Notable examples include Binance tss-lib [5], Zengo-X [7], and ING-bank [6].

Application and adoption status

Our primary focus will revolve around Binance’s TSS implementation, known as TSS-Lib, which has been openly available since 2019 [5]. This implementation has gained significant traction in the DeFi space, attributed in part to its permissive MIT license, making it a popular choice for numerous projects like Joltify-bridge [10], Thorchain TSS [11], and ioFinnet threslib [12]. TSS-Lib supports both ECDSA and EdDSA natively, with both variants relying on elliptic curve cryptography as their foundation.

Known Vulnerabilities and Security Patches in TSS-Lib

TSS-Lib underwent a comprehensive audit by Kudelski Security in 2019 [13], resulting in the identification of several vulnerabilities. However, the Binance team promptly addressed all the issues, resolving seven medium-severity vulnerabilities and three low-severity vulnerabilities.

In 2021, a significant vulnerability with a high severity rating, CVE-2020–12118 [14], was discovered in the keygen protocol used by popular threshold signature schemes GG18 [1] and GG20 [16]. This vulnerability, detailed in [15], primarily affects the fast variant MtA (Multiplicative to Additive) due to the absence of zero-knowledge range proofs. Exploiting this vulnerability allows attackers to manipulate h1 and h2 hash parameters, potentially compromising signing rounds or extracting sensitive information from other participants. TSS-Lib was also impacted by this vulnerability, but the Binance team swiftly addressed it by releasing version 1.2.0 [17]. Subsequent updates, such as version 1.3.3, further patched various security issues within TSS-Lib, including the rectification of missing format checks for Pailler ciphertext and the addition of length verification for NTildej. The most recent version of TSS-Lib is 1.3.5, released on September 23, 2022.

Discovery of Vulnerabilities in Similar TSS Implementations

The field of Threshold Signature Schemes (TSS) has witnessed recent vulnerabilities in comparable implementations. In December 2022, Verichains, a prominent blockchain security audit firm, publicly disclosed a critical key extraction vulnerability in fastMPC [25], an ECDSA TSS implementation based on GG20 [16]. In fastMPC, the iteration parameter used in the NtildleProof was set to 1 instead of the required 128 as specified in the GG20 paper [16]. This oversight renders the proof susceptible to forgery, enabling an attacker to extract the private key by participating in just one signing round.

Furthermore, in March 2023, io.Finnet revealed four vulnerabilities discovered by Kudelsky Security during an audit [18] of their threshold ECDSA signature implementation [12]. These vulnerabilities are identified as CVE-2022–47930, CVE-2022–47931, CVE-2023–26556, and CVE-2023–26557, respectively.

Additionally, on March 28, 2023, Verichains reported another critical key extraction attack on popular TSS implementations utilized in MPC wallets and digital asset custody [26]. According to the audit firm, this vulnerability affects most widely-used TSS implementations in Go or Rust, which are based on GG18 [1] and GG20 [16]. The official disclosure is pending until the vulnerability is patched, but it is highly likely that TSS-Lib will be among the impacted implementations.

The Impact of ioFinnet’s TSS Vulnerabilities on TSS-Lib

ioFinnet’s threslib [12] presents a variant of ECDSA TSS, as outlined in [19], that draws significant inspiration from GG18 [1]. The primary distinction lies in its requirement for only the final round to be conducted online, allowing the pre-calculation of preceding rounds. This design proposes a partially non-interactive threshold ECDSA scheme. Given the strong influence of TSS-Lib on ioFinnet’s threslib, it raises the question of whether the recent CVEs discovered in ioFinnet’s implementation are applicable to TSS-Lib. In the following discussion, we will examine the nature of these vulnerabilities and their potential impact on TSS-Lib. It is important to note that all perspectives expressed here are based on the commit bb6fb30 in the repository: https://github.com/bnb-chain/tss-lib/.

CVE-2022–47930: Vulnerability to Replay Attacks Involving Proofs

Replay attacks pose a significant threat to multi-party computation (MPC) protocols, necessitating the use of zero-knowledge proofs for participants to validate parameters and prevent cheating. However, ioFinnet’s threslib [12] overlooked the inclusion of the session ID (ssid) in message exchanges, a crucial component described in the base paper [19]. This oversight allows for message replay and spoofing in specific scenarios. In contrast, TSS-Lib explicitly emphasizes in its README, particularly the “How to use this securely” section, the requirement of linking each message with a unique session ID during keygen, signing, or re-sharing rounds. For instance, Figure 1 [20] highlights that TSS-Lib does not, by default, incorporate a unique session ID in the challenge used for Paillier key proof. Consequently, malicious users or eavesdroppers can replay previously sent valid proofs.

Figure 1: TSS-Lib SHA512–256 function does not include session id by default

As a result, TSS-Lib is currently vulnerable to replay attacks when dealing with proofs. It falls upon the implementer to ensure the adoption of a secure transport mechanism that utilizes out-of-band agreed-upon unique session IDs before each round, mitigating the risk of such attacks.

CVE-2022–47931: Collision of Hash Values

Both ioFinnet’s threslib [12] and TSS-Lib implementations utilize SHA512_256 and SHA512_256i functions for hashing bytes and integer tuples into bytes. However, they employ the delimiter “$” to separate different parameters without considering the possibility that the “$” symbol may be part of the concatenated values. As illustrated by Kuldelsky Security [18], this oversight leads to hash collisions. For instance, the hash values of the pairs (a$, b) or (a, $b) would yield the same hash value of (a$$b). According to the stringent requirements stated in GG18 [1], the chosen hash functions should be derived from random oracles, rendering the discovery of collisions infeasible.

TSS-Lib is vulnerable to this issue due to its utilization of the same code as ioFinnet’s threslib [12]. However, this vulnerability was addressed three weeks ago [21], as demonstrated in Figure 2.

Figure 2: TSS-Lib patched the hash collision vulnerability on the 24th March 2023, 1 day after the ioFInnet public disclosure

As depicted, the solution involves systematically appending the length of each byte buffer to the end of the data buffer before calculating any hash values. This approach effectively resolves the collision problem, providing an elegant fix for the issue.

CVE-2023–26556 and CVE-2023–26557: Non-constant-Time Arithmetic Vulnerabilities

These vulnerabilities pertain to the usage of non-constant-time arithmetic in critical cryptographic operations.

CVE-2023–26556 addresses the utilization of the big.int input type, which lacks constant-time implementation, rendering it susceptible to timing side-channel attacks. It’s worth noting that constant-time property ensures that the trace of instructions fetched and memory addresses read remains consistent across all inputs. TSS-Lib extensively employs the big.int type throughout its codebase, with approximately 64 occurrences [22]. However, big.int, being part of the math/big module in Go, does not provide constant-time arithmetic. As a result, the non-constant time properties present a risk of leaking private data when performing arithmetic operations like comparison, modular inverse, or modular exponentiation on sensitive values. It is noteworthy that math/big is being phased out from the standard crypto module, starting with the release of Go version 1.2.0 in 2022 [23].

On the other hand, CVE-2023–26557 revolves around the utilization of the elliptic curve secp256k1 in the ECDSA TSS variant. Regrettably, this curve solely supports non-constant-time scalar multiplication operations, rendering it unsuitable for secure cryptography implementation. Similar to CVE-2023–26556, this vulnerability can be exploited through timing attacks to deduce the private values employed in scalar point multiplication.

To summarize, from our perspective, TSS-Lib remains vulnerable to the new security issues discovered in ioFinnet’s threslib [12]. The maintainers have only addressed the potential hash collision issue thus far. In the subsequent section, we will examine the dependencies utilized by TSS-Lib and share our assessment of their security posture.

Dependency Vulnerability Assessment

Presently, the Binance TSS library remains based on Go version 1.16, while the current version of Go is 1.20.3. TSS-Lib relies on multiple dependencies, yet most of them are outdated.

To verify our concerns, we examined the utilized dependencies and searched for vulnerabilities in the official Go vulnerability database [2]. Our investigation uncovered several issues. To further validate our findings, we employed the govulncheck tool [3] to scan for known vulnerabilities affecting the Go code. The raw scan results provided by govulncheck are available for verification in Annex A.

Within Annex A, we discovered six vulnerabilities with direct call stacks within the code. Additionally, 27 vulnerabilities were found in packages imported by TSS-Lib. However, these vulnerabilities were not triggered by any call stacks associated with TSS-Lib usage. The table below highlights the vulnerabilities that, in our view, require mitigation. It is important to note that we only list the vulnerabilities found in the dependencies actually employed by the implementation, excluding any false positives. Furthermore, we disregard findings in test files or vulnerabilities present in packages imported by TSS-Lib but not utilized.

Please refer to the table in Annex A for detailed vulnerability information.

Additionally, it is important to highlight that the crypto/elliptic module has been deprecated since the release of Go 1.2.0 due to its hardcoded dependency on the variable-time, large, and complex math/big package [27]. For advanced usage of elliptic cryptography, it is recommended to switch to alternatives such as crypto/internal/nistec or crypto/internal/edward25519. These alternatives eliminate the reliance on backend field arithmetic from math/big and provide constant-time, heap allocation-free, and byte slice-based safe APIs [28].

Recommendations for using Binance’s TSS implementation

While TSS-Lib stands as one of the most acclaimed and widely-used elliptic curve-based TSS implementations, it is currently best suited for development purposes to gain a deeper understanding of TSS functionality. Should you consider integrating TSS-Lib into your blockchain project for production, we strongly advise following these recommended practices:

Adhere strictly to the security guidelines provided by TSS-Lib contributors [6], specifically the section on “how to use it securely.” This includes utilizing secure and reliable transports, such as TLS, for broadcast and peer-to-peer communications among signers.

Keep the TSS implementation up-to-date by promptly patching any recent vulnerabilities discovered through security audits.

Address and mitigate any vulnerabilities present in the dependencies utilized by the TSS-Lib.

Remove modules that lack support for “non-constant time” operations and prioritize standard crypto modules compatible with recent versions of Go.

Implement static code and dependency security checks using tools like semgrep or snyk for all pull requests (PRs), if feasible. Such checks will aid in the early detection of security issues during the development process.

Pay close attention to the theoretical requirements outlined in academic papers when implementing cryptographic protocols. Deviating from these requirements can be intricate and may have significant financial implications within the blockchain space.

Seek regular reviews from security experts to ensure that changes made to the TSS implementation do not compromise its security posture.

Conclusion

In conclusion, this article has provided a comprehensive analysis of the vulnerabilities discovered in the Binance TSS implementation. Based on our assessment, it is evident that this library is not currently suitable for production use, unless all identified vulnerabilities and outdated dependencies have been thoroughly addressed through proper patching. It is crucial to recognize that this implementation should be regarded primarily as a library for generating threshold signatures, rather than a comprehensive threshold signature protocol.

To ensure the security and robustness of your own TSS implementations or other blockchain projects, it is advisable to seek the expertise of professional security firms. Arcadia (https://arcadia.agency) specializes in software security audits and offers a range of services to enhance the security posture of your systems. Consulting with Arcadia and leveraging their expertise can provide invaluable insights and assistance in identifying and mitigating potential security risks concerning the topics discussed in this article.

Footnotes and References: https://gist.github.com/HysMagus/4ee51a3c81ce3b3cd4061a3b66175852

Unveiling the Secrets of Binance’s TSS: Adoption, Vulnerabilities, and Security Analysis was originally published in The Arcadia Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

The PoolZ Token Vesting Contracts were hacked yesterday (March 15, 2023). The hack occurred at 03:16 AM +UTC on BSC, 03:09 AM +UTC on Ethereum, and 02:59 AM +UTC on Polygon. This hack was first detected by Bythos and swiftly reported upon and analyzed by the security firm, Peckshield.

The vulnerability that led to this unfortunate incident, an arithmetic overflow attack, occurred in the unaudited LockedControl.sol in the Integrate repository.

The hacker was able to utilize an overflow vulnerability in the highlighted point in the contract, by which they created multiple pools for each asset type while committing substantive assets that they did not have that cumulatively hit the cap of the token contract limit (MAX U256) overflowing it to zero thus allowing for the attacker to deposit zero while getting a credit balance for the overflow amount. This is done by the hacker calling CreateMassPools function. This then allowed the hacker to call the WithdrawToken function withdraw the assets from the created pools without having deposited the corresponding amounts.

This vulnerability is not as easily possible in later solidity versions (the contract is written with the solidity version 0.6.0) as native overflow safeguards were added in later versions.

Other versions of this vulnerable code exist in an unaudited and currently unused array.sol . We believe this version would not be exploitable as easily due to arithmetic overflow safeguards in later solidity versions. Nonetheless, we have recommended the complete removal of that library for safety.

Our thoughts are with the PoolZ team during this challenging time, and we have made our team available to them for any assistance we may be able to provide.

Post Mortem: PoolZ Token Vesting Contracts was originally published in The Arcadia Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

It is no secret that in current markets, security firms in the industry are contending with massive waitlists and backlogs for blockchain security services, from code reviews to incidence response planning.

As a means to combat that and to ensure prioritization of projects that will have a lasting factor beyond the average lifespan of a DeFi project (~3 weeks) as well as provide some sort of incrementation in growth to the industry, Arcadia is instituting a prioritized waitlist to help alleviate wait times.

This waitlist will be based on specific factors such as (but not limited to):

• Project Innovation
• Project Risk Level (to Users and to Themselves)
• Project Client Fit

As a means to ensure that we are not only servicing new customers but also assisting in the growth of longstanding clients, partners, and projects we support, we will be providing priority (and scaling discounts) on our waitlists to projects who

• Who are utilizing client technologies such as StakedXZC (Firo)
• Utilize Decentralized Web3 Technology such as Pokt.Network

Interested in getting audited, building an incidence response plan, or launching your next project? Fill out our new contact form today!

Announcing Arcadia’s Prioritized Waitlist was originally published in The Arcadia Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kamish Rehmatulla, alongside Rasikh Morani & Ivan Nava, co-founded Arcadia in November 2017. Kamish Rehmatulla acted as Arcadia CEO throughout the operations of Arcadia from November 2017 to July 2020, and has announced his exit from Arcadia

Arcadia started as a marketing services operation in June of 2017, During Kamish Rehmatulla’s leadership, Arcadia transitioned into a software development operation in early 2018, servicing primarily utility tokens developing peripheral assets.

Under Kamish’s leadership, Arcadia moved to a significantly deeper operation, focusing on more technical aspects of blockchain development inducing working with privacy protocols, network architecture, and scaling solutions. Arcadia’s sales processes evolved under Kamish, with multiple of Arcadia’s initial clients being introduced under his management.

Arcadia continues to operate under Rasikh Morani, Kamish wishes for the best of success and looks forward to our newest product the Arcadia Wallet.

Rasikh is well versed in the technical aspects of blockchain, consistently present in the modern industry, and will drive forth the newer milestones of success.

As Kamish says farewell to Arcadia he moves on to delve deeper into ventures in the financial service and software industry in the arena of hospitality and retail. Acadia will continue to be creative and serve its customers with industry-leading technologies. We wish Kamish Rehmatulla the best of luck in his new endeavors!

Announcing Arcadia CEO Transition was originally published in The Arcadia Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here at Arcadia, it’s no secret that we’re big fans of Pocket Network and the movement of simplified network communications. Arcadia is also big on the ways security in our industry can adapt and grow to prevent loss of user assets and value.

One of the intersections of such these two loves of ours is in the arena of exchange security through Pocket. In the progression of our business operations over the years, Arcadia has had the pleasure of working alongside our clients during the listing process. We’ve also had the pleasure of developing a small number of cryptocurrency exchanges for clients as well. In that time we’ve come across a few constant problems across the vast majority of exchanges in the industry. These constants are the following,

• Exchanges often maintain 1–3 full nodes for communicating with the blockchains they are providing trading pairs for
• Node upgrade timeframes and coordination are often centralized, and time-consuming (and sometimes costly)
• The low number of nodes communicating with the network on behalf of the exchange leads to higher susceptibility to forks, DDOS attacks (directly focused on exchange nodes), and other targeted attacks that can and have led to a loss of funds.

Pocket’s network of decentralized node operators alleviates if not solves the above problems on multiple levels. Pocket by the nature of it’s offering solves the problem of a limited number of operating nodes on listed coins without causing bloat in the overarching server and related development operation costs.

Thanks to the slashing and jailing functionality present within the Pocket Ecosystem, there is a reasonable degree of trust on the communications network to have the updated node versions, and longest chain whenever possible. Thus preventing exchanges from entering onto short-range difficulty-related forks, and hard fork-related chain forks. This paired with the ability to communicate with multiple nodes with a couple of API calls and the ability to easily wrap the Pocket Client in a way that is JSON-RPC compatible, Pocket comes out as a great solution for targeting the problems raised earlier in the article.

Pocket’s ability to lower the attack surface for DDOS attacks and increasing the cost for DDOS-attacks, in general, allows for uptime and network communications to remain stable and constant while preventing massive spikes in upkeep costs and DDOS-protection.

These reasons alongside others, including some benefits in the arena of hot wallet management and transaction announcement (which we’ll be covering in a future article), is why we will be implementing Pocket as a core element within our exchange development stack.

How Pocket can change the way Exchanges interact with overarching networks was originally published in The Arcadia Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

The usage of phone numbers as a medium of verification for anti-spam and identify purposes on websites throughout the web is a growing trend with unsettling consequences in the arena of individual user privacy.

With this unsettling trend, there has been a counter trend of verification-as-a-service providers who provide temporary phone numbers for verification. These solutions are not without their flaws, with most services facing issues in the arenas of user transactional privacy (they have you user card in an easy traceable manner), miss-apportionment (phone numbers are shared between too many participants leading to unintentional banning), and issues in regards to extraneous data (they store request information like name and email).

This does not mean there are no good solutions, Phitbone is a anonymous text verification rental service, covering the three aforementioned flaws, through it’s usage of zcoin as a means for transactional privacy, fair apportionment standards using an hourly rental system, and minimal data collection.

For the uninitiated, zcoin is one of the more mature privacy coins in the space (created in 2016), which takes advantage of a privacy protocol called Sigma, which allows for users to break the transactional links between transactions using a sanitatization process called minting.

The transactional process known in short hand as “Mint. Spend. Repeat” follows as such:

1. You can acquire zcoin through a plethora of means, check out the Zcoin website to see some options
2. Upon the reception process of zcoin you can anonymize your coins using the Sigma page by inputting the number of coins you’d like anonymize and clicking the mint button (Here’s an awesome guide)
3. Once you’ve anonymized your coins, you can use the “Spend” option on the sigma page to send your coins to a recipient with no associated transactional history

In the context of Phitbone, the first step is to head to https://phitbone.com and create an account.

Upon providing your minimal hopefully non-identifying username or password (yes, you can be deanonymized using your password) you will need to attest that you’ll remember your password and that you recognize that without your username and password you will be left without hope of recovery.

Upon entering into your logged in account, you will be able to click the only available option for purchasing a number:

Once you click that button, you will have the option to select the number of hours you will need the number. Don’t worry, if you need to reuse a number after your time has expired, you are free to renew your time on the number if it is available at the time of renewal.

On the purchase page, you will be able to click the payment method option listed zcoin (it’s the only option available outside of USD).

On your zcoin wallet, you will be able to use the spend option on the sigma page, to input the address and send the requisite amount of zcoin to the site.

There will be a slight delay of delivery as the prerequsite number of confirmations is met.

Once you’ve purchased a number you will be able to send and receive messages from the messages tab on Phitbone

You will also be able to renew and purchase additional hours on the service from the Purchase Tab on site

After you have completed all of these steps, congratulations! You now have a number that’s been acquired in a transactionally anonymous manner.

Now this does not mean your purchase is untraceable, there are still a number of potential pitfalls you may face. With one of the key ones being network privacy. Here’s a great guide on using TOR to hide your browsing activity from your ISP, and other nosey individuals.

As promised in our previous article covering our last contribution to the Zcoin community, we have returned with another Implementation Analysis! This implementation analysis is particularly special, as it’s the first one funded solely by the Zcoin Community Funding Tool, the “ZCS”, a tool that allows for community members to fund projects of interest for the Zcoin Community.

Arcadia recently completed integrating ZCS Proposal #7, “Integrating Coin Control Functionality into the Zcoin Rich Client”

The Zcoin Rich Client, is a more user-friendly implementation of the traditional Zcoin Wallet, with the same security spec.

This was an interesting first project on the Zcoin Rich Client, as there was a learning curve on the side of how ZMQ communications were implemented, specific implementation choices, and functionality on how Sigma mints are treated when they are being spent.

Our UI/UX process began with our team going and reviewing the existing implementation of Coin Control on the reference Wallet, then attempting to replicate that on the Rich Client while adding some easier UI elements for accounting for Znodes among other considerations.

Our development process began with a run-through of how coin control on the primary wallet (QT) worked on a user flow level, and on an operational level. At the same time, we began reviewing the architecture and compilation processes for the coin control functionality.

We ran into some initial issues with compilation and testing but after some extensive communication with the maintainers, we were able to get a good idea on where we were erring.

After our environments were set and we were able to quickly compile and were somewhat familiar with the codebase, we began implementing the expected API calls on the side of the daemon (ZMQ API).

Once that was complete, we began the process of building out the frontend UI for the rich client and hooking it up to the previously created APIs for Coin Control functions for both the Sigma and Normal Transaction Screens.

After the integrations were done, we did some remediation with the Zcoin Team, where they gave us some pointers on how we could modify the handling of Transaction Events to be more efficient and user-friendly for users with a large number of transactions. As well as updating some UI/UX updates for a better experience.

This project was a bit different than what we were used to, but overall it was definitely a success. We’d like to thank Tadhg Riordon for the major assistance in working with the Rich Client codebase of which he and Praxit are the primary maintainers. We’d also like to thank Reuben Yap for the amazing support and coordination.

Implementation Analysis: Coin Control on the Zcoin Rich Client was originally published in The Arcadia Group on Medium, where people are continuing the conversation by highlighting and responding to this story.