Month: May 2024

Company Name: DEMAND

Founders: Alejandro De La Torre and Filippo Merli

Date Founded: 2023

Location of Headquarters: Lisbon, Portugal and Florence, Italy

Amount of Bitcoin in Treasury: “Currently being bootstrapped”

Number of Employees: 2

Website: https://www.dmnd.work/

Public or Private? Private

Alejandro De La Torre is deeply concerned that Bitcoin mining is too centralized, and he’s on a mission to change that. This is why he started DEMAND, a Bitcoin mining pool that puts power back in the hands of independent Bitcoin miners.

Before getting into how DEMAND works, though, it’s important to understand what De La Torre has learned from his time in the Bitcoin mining industry so as to better understand his motivation in starting DEMAND.

De La Torre’s History In The Bitcoin Mining Space

De La Torre has served as the VP of Poolin, one of the largest Bitcoin and crypto mining pools in the world, as well as the VP of Business Operations for BTC.com, which also operated its own Bitcoin mining pool. What he saw during his time in these two roles made him realize that there was little time to waste in decentralizing the Bitcoin mining landscape.

“The experience I had in the last pools made me realize that we needed a change in the mining pool industry and we needed it very, very quickly,” De La Torre told Bitcoin Magazine. “There’s a very clear problem with centralization in mining pools today, and I was able to pinpoint that issue while working at BTC.com and Poolin.”

De La Torre went on to describe how many Bitcoin mining pools are now proxies for a larger pool, which he didn’t mention by name (it’s Antpool), and explained that such centralization has the power to seriously damage Bitcoin.

“The anchor pool is close to 50% of the network now. It allows for a 51% attack on the network, which would be catastrophic,” said De La Torre.

“I don’t think they would ever do it, but the possibility is there, which is already a huge red flag,” he added.

De La Torre also pointed out that such levels of centralization pose risks when it comes to network censorship, highlighting that it wouldn’t be difficult for this major pool to censor half of the transactions on the Bitcoin network.

The potential for censorship and a 51% attack “are a very clear and present danger that we have in Bitcoin right now,” according to De La Torre.

Power To The Solo Miners

In reaction to this, De La Torre and his business partner, Felippo Merli, launched DEMAND Pool in November 2023 with the intention of putting the power back in the hands of solo miners.

DEMAND is the world’s first Stratum V2 mining pool. Stratum V2 is an open-source messaging protocol that enables miners and pools to communicate directly with each other, reducing mining infrastructure requirements compared to its previous iteration, and enabling solo miners to choose their own mining templates. This latter capability is one of the major features that sets Stratum V2 apart from other mining pool protocols.

“Pools today are the ones who are in charge of building the blocks and adding the transactions into the blocks,” said De La Torre. “With Stratum V2 — with DEMAND — the miners themselves will be able to build the blocks and add the transactions that they want.”

Most filtering in mining pools today is done at the pool level, not the individual miner level. De La Torre understands that especially in the wake of the introductions of protocols like Ordinals and Runes, miners want more control over what types of transactions they include in their blocks. And De La Torre believes miners should have this power, because it adds to the ethos of decentralization.

“This gives me less power. That’s what I want. I don’t want the power. I’m done with that power,” said De La Torre. “I’ve had it before, and it’s too much power in the hands of too few. And that’s not what Bitcoin is. Bitcoin is decentralization, and this is furthering that.”

In efforts to help miners with filtering, DEMAND has created a series of mining templates that miners can readily use in their operations.

Incentivizing Solo Miners

De La Torre is aware that the odds of mining a block are against small-scale solo miners, but he doesn’t think they shouldn’t give finding one a shot, and he’s also created other ways to incentivize solo miners to come online.

“You’ve got to heat up your home during winter, right? Why not just use a Bitcoin miner as a heater?” said De La Torre.

“If you’re lucky, you hit a block and you just made your wife very happy,” he added with a laugh.

Solo miners who join DEMAND Pool will also have the option to sell the hash rate they produce on a marketplace, ensuring that they receive some income for their efforts. DEMAND has set up a deal with the hash rate marketplace Rigly and plans to establish more partnerships.

De La Torre also touched on how DEMAND payments will be done via the PPLNS (Pay Per Last N Share) system. With PPLNS, profits are allocated based on the number blocks a mining pool mines per day and payouts fluctuate based on the pool’s luck in mining blocks.

This system differs from the FPPS (Fee Pay Per Share) system, which is commonly used in the major mining pools. With FPPS, miners charge a service fee based on theoretical profit, and miners get paid whether the pool finds a block or not.

De La Torre is aware that it may sound attractive to miners to get paid consistently with FPPS, but he was quick to point out that payouts through both PPLNS and FPPS are comparable over the long term.

“A lot of people have some misunderstandings about PPLNS,” said De La Torre.

“FPPS gives you constant payouts, which is fine. I understand why a miner would find FPPS. However, PPLNS over enough time averages out to about the same,” he added.

“Yes, you won’t have constant payouts, but you will have incorrect payouts according to how much hash rate DEMAND has — and we intend to have a good amount. You will still be getting a constant payout, or it would average out to more or less the same. So, there’s no real downside to it.”

De La Torre also pointed out that solo mining as part of DEMAND’s pool is one of the best ways for Bitcoin enthusiasts to get their hands on non-KYC bitcoin.

He also stressed the fact that solo miners’ coming online will do something else that’s vital to keeping Bitcoin decentralized — it will bring more nodes online.

Send Nodes

To use DEMAND’s block templates, miners have to run their own nodes. This means that solo miners would not only contribute to the decentralization of Bitcoin’s hash rate but also to the decentralization of its governance.

“Not only do we want the solo community and the home mining community to flourish and to make more money, but we also want node proliferation,” said De La Torre.

“Solo miners will provide hash rate to secure the network and potentially make some bitcoin and also help with maintaining Bitcoin Core or whatever Bitcoin client they want. Nodes are good for the health of the system,” he added.

Looking Ahead

De La Torre also said that DEMAND is currently working on expanding its services to pooled mining, and that DEMAND will actively be looking for miners to come on board.

He’s vowed to make DEMAND a “stable and trustworthy pool with transparent payouts,” differentiating it from the “black box” pools out there.

De La Torre seems to be doing everything in his power to bring more independent miners online, and as he laid out his plans for DEMAND in my conversation with him, there was a palpable sense of urgency in his voice.

“The centralization of Bitcoin mining pools is becoming a very serious issue, and it’s up to us as the mining community to do something about it,” said De La Torre. “If we don’t, it’s not good.”

Is OP_CAT happening? The covenants proposal was just assigned BIP number #347. But before we delve deeper, let’s explore what covenants are and why Bitcoiners may want them.

Is Bitcoin an ideal state of digital e-cash or do we want more from our coins on-chain?

Scratching the Surface: Bitcoin Scripts Limitations

To understand covenant proposals like OP_CAT, it’s crucial to grok the fundamental limitations of Bitcoin Script as it is today. Under the hood, Bitcoin allows for the creation of basic smart contracts through codes that define the rules for locking and unlocking funds. However, Bitcoin Script, as a programming language, is fairly limited to basic logic that comes into play only when moving coins in a new transaction.

In Bitcoin today there is no way to pre-configure or dictate your coins’ transaction paths, or how fast coins can move at the time they’re being locked up (aside from hacky workflows using PSBT, partially signed bitcoin transactions, which cannot properly include transaction fees, prove deletion if unused, or prevent broadcasting later).

This simplicity, while core to Bitcoin’s security model, introduces significant limitations in the scripting language’s ability to support even basic smart contracts.

Linear Execution Model

One limitation of Bitcoin Script is its operational model where opcodes are executed sequentially with no loops.

From this example of a P2PKH transaction, you can see how the script executes linearly: duplicating the public key, hashing it to an address, verifying the hash against the lock script, and finally checking the signature against the public key.

The absence of looping means that scripts are not Turing complete and are guaranteed to terminate, preventing issues like infinite loops that could potentially halt or significantly slow down the network. While this design choice allows resource usage to be statically bounded, it also limits Script’s capability to manage complex workflows.

Lack of Basic Arithmetic

Bitcoin Script has just under 100 nontrivial opcodes, and somewhat surprisingly there is no ability to multiply, divide, or combine objects on the stack. As many users interested in OP_CAT will know, Satoshi disabled several opcodes in Bitcoin in 2010, including OP_OR, OP_MUL (multiply), OP_DIV (divide), and OP_CAT (concatenate) among others. The disabled opcodes were removed because their original implementations had exploitable vulnerabilities that could compromise the network’s security. But the absence of these opcodes makes it difficult to do basic math, which could be useful in simple scenarios like calculating transaction fees in a contract.

Lack of Transaction Data Visibility

Superficially, I think most people assume that Bitcoin smart contracts are able to see value amounts and any other parts of transaction data, since this information is already publicly viewable on the blockchain. But contrary to this assumption, contracts on Bitcoin are not able to set spend conditions based on transaction data, because Bitcoin Script has a very limited ability to see into transaction data at all.

If script had the ability to interpret more details within transaction data, we could build much more robust contracts that could do all the fun things like enforce specific spending conditions, create multi-stage transactions, and enable more advanced security features like vaults.

What do we do about it?

We know Bitcoin has these limitations, and over the years many different proposals have been discussed to introduce (or in some cases reintroduce) this functionality. Broader experiments with Bitcoin Script, such as Simplicity and others, aim to provide an alternative to stack-based constraints. Opcodes like OP_MULTISHA256, OP_LESS, and OP_LE32TOLE64 aim to upgrade Bitcoin’s arithmetic abilities. Proposals like OP_CTV and OP_CAT that deal with introspection opcodes are grouped under the term covenants.

So what exactly is the difference between smart contracts and new term covenants?

Smart Contracts vs. Covenants

Smart contracts are self-executing transactions that transfer funds without intermediaries. In Bitcoin today, the smart contracts are limited to the act of locking and unlocking bitcoin with Bitcoin Script. Covenants aim to enhance Bitcoin’s smart contracts functionality by enabling users to control how their funds are spent in future transactions.

By enabling Script to interpret transaction data, we effectively create a way for that data to be used in contract logic.

These are just some of the more interesting introspection opcodes for covenants functionality:

OP_TXHASH: Provides the hash of a transaction’s inputs (or outputs), and gives Script the ability to verify and enforce conditions based on transaction data.OP_CSFS + OP_CAT: The two together allow scripts to check signatures against any data, not just the transaction itself. This means Script can verify conditions based on transaction data or external information, expanding the possibilities for validation within Bitcoin scripts.

These two opcodes are intentionally broad, enabling complex validation processes and introspection capabilities. Others are more narrow in scope and are designed to be a more limited form of covenants.

OP_CHECKTEMPLATEVERIFY (CTV): Allows a transaction output to embed a template of a future spending transaction, enabling covenants in a more constrained way.OP_VAULT: Enables a specific form of covenant used for “vaulting”, which lets users specify a transaction destination but not actually move coins except after a delay.

Then there is OP_CAT on its own, which is not directly an introspection opcode…

OP_CAT: Enables Script to concatenate two elements on the stack, which is useful for combining different pieces of information within a script.

OP_CAT doesn’t seem to have any introspection abilities, so what’s going on here?

OP_CAT: Unraveling All of the Possibilities

Transaction Introspection

In 2021, Andrew Poelstra wrote about OP_CAT introspection tricks in a blog post. He provided specific examples but presumed readers had prior knowledge of similar techniques. Here, I’ll aim to simplify that explanation for better understanding.

In Bitcoin Script, there are only three primary opcodes that allow you to introspect the transaction data: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, and CHECKSIG. Additionally, there are variants like CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, and CHECKMULTISIGVERIFY, which are essentially minor variations of CHECKSIG. The first two only let you see if the check is verified, providing a fairly narrow functionality. CHECKSIG is similar, but the difference here is that it allows you to grab the signature and the public key on the stack. Interesting.

Traditionally, we think of concatenation as a function that joins two items together, but we can also use it to separate or split an item, in this case—the signature into an (r, s) pair.

How do we derive OP_SPLIT functionality from OP_CAT?

“If you have some big object you can split it into two by asking the user to spend time to provide the two pieces. You CAT them together and check equality basically. You can always invert every operation this way. With CAT by itself you can break apart signatures.” — Andrew Poelstra, TABConf 2021

What is happening here?

By requiring the user to provide the signature, public key, and transaction, you can split the signature into its component parts, then checking each part independently against the transaction data. This technique can be viewed as a form of splitting or combining, as it validates that the signature and public key are indeed the components of a valid transaction.

How does all this get us introspection?

“In Taproot where we have Schnorr signatures using OP_CAT and the Schnorr signature verification opcode it turns out that it is possible to get a form of non-recursive covenant where you literally get a transaction hash. Not even like a funny mangled transaction hash but a literal SHA2 hash of all the transaction data onto the stack.” — Andrew Poelstra, TABConf 2021

Poelstra goes on to demonstrate how you can get a SHA2 hash for transaction inputs or outputs left on the stack. We’ll skip the moon math here, but the implication is that with OP_CAT we can constrain parts of a transaction as a requirement of the unlocking script. We can constrain the send address or value being sent of that transaction, where the transaction hash serves as the key to unlock it.

Vaults

Using the same techniques give us transaction introspection and quickly give us a basic version of vaults. Following the logic outlined in Poelstra’s blog, a developer by the name of Rijndael proved that we can do this with OP_CAT alone in his implementation of Purrfect Vaults.

“Re-building a TXID on the stack to introspect previous transactions was actually easier than I expected.” — Rijndael

With vaults, users specify the next address that their funds must go to, providing mechanisms for fund recovery in case of key compromise, and reducing the incentive for private key theft.

Merkle Trees for Script

In Bitcoin today, Merkle Trees are the data structure used for data verification, synchronization, and more or less ‘chaining’ the blockchain’s transactions and blocks together. The OP_CAT opcode, which enables the concatenation of two stack variables, when used alongside SHA256 hashes of public keys, facilitates a straightforward Merkle tree verification process for scripts. This approach, initially proposed by Pieter Wuille in 2015, was successfully implemented in the Liquid network.

Imagine a tree structure brimming with various spending conditions, such as hash preimages, timelocks, and public keys, known as tree signatures.

Tree Signatures

OP_CAT enables the creation of Tree Signatures which:

“…Provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance, a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.” — BIP author Ethan Heilman, on the bitcoin-dev mailing list

This would enable the validation of any hashed content within the tree, maintaining data integrity and trustworthiness without adding unnecessary bulk or bloat to the blockchain.

What is interesting about all of this?

Recursive Covenants

If you have the ability to examine a transaction and apply constraints to certain parts of it, you can set up conditions that carry over through multiple transactions, effectively creating a chain of ongoing restrictions. This concept is called a recursive covenant. OP_CAT is a unique proposal because it gives us so much power for just 10 new lines of code. It has the ability to address all three of the initial limitations we covered at the onset of the post: transaction data visibility, better math functionality, and its linear execution model.

While OP_CAT may seem straightforward at first, it unlocks significant potential when leveraged creatively. It serves as a building block for even more functionality way beyond the scope of this discussion, like Post-Quantum Lamport Signatures.

Is This Safe?

Before OP_CAT was initially removed, when combined with OP_DUP (duplicate), and used repetitively to duplicate an initially-1-byte value on the stack, memory usage could be made to explode. This could have been used as a denial-of-service (DoS) attack as a result of increased memory consumption. The new proposal trivially prevents this attack by imposing a 520-byte limit on stack elements.

Is there a danger of a contract running forever?

If by this we mean, does OP_CAT change the execution model of Script to mean that it no longer statically bounds its resource usage (as a linear function of the Script size)? No.

Would covenants create a market for other coins on top of Bitcoin?

If you have a recursive covenant, yes, you can technically build up complex layer-2 applications, including NFTs, decentralized exchanges, and quantum cats. However, doing so is not trivial. It’s hard to see any serious markets do so.

Can you permanently “taint” coins by using CAT?

In the case of colored coins and NFTs, issuing these assets the user effectively ‘burns’ a satoshi, marking it in a way that signifies ownership of the ‘layer-2’ asset. This process is known as ‘tainting’ coins. But only the owner of a coin can mark their coin, and Bitcoin wallets will no longer recognize it (unless their authors explicitly add code to enable this). The resulting coins would not be accepted by bitcoin wallets. Probably they would be accepted by cryptocat wallets or something like that, but this is irrelevant to most bitcoin users.

Would this create an MEV problem on Bitcoin?

A key point of distinction between Bitcoin and Ethereum is transaction visibility. Unlike Ethereum, not all aspects of the contract are necessarily transparent, meaning that Bitcoin miners don’t have the same ability to see internal contract state and front-run them.

The main concern of OP_CAT by economically minded Bitcoiners is the potential for Miner Extractable Value (MEV). As discussed more extensively in my previous post on the subject. Many users are concerned that if we make layer-2 contracts technically possible, MEV will become inevitable. But is this true? Specifically, does the technical feasibility of layer-2 coins on Bitcoin imply their inevitable creation and adoption?

You could imagine building simple swap contracts or comparatively inefficient NFTs, but building up something as complex as DEXs with automatic market makers seems extremely unlikely and is not ever something we’ve seen on Liquid despite the ‘technical possibility’ for it.

So is OP_CAT really perfect?

Hardly, far from it. Some folks would love to see recursive covenants, while others simply don’t want to see Bitcoin change at all.

A faction of Bitcoiners, “ossificationists”, advocate for preserving Bitcoin in its current state and view any protocol upgrades with skepticism. They are particularly concerned that significant changes, like the introduction of covenants, could undermine the network’s decentralization. Their argument hinges on the belief that it’s best to stick closely to Bitcoin’s original vision. The irony being that OP_CAT was initially part of Bitcoin, fuels a counterargument. Some believe that bringing OP_CAT back could actually realign Bitcoin with Satoshi’s initial vision.

If you’d like to see some of the security features that recursive covenants could make possible, OP_CAT would be nice, but definitely not as nice as a full-blown Lisp-esque scripting language. The problem here being that this would be a massive change to Bitcoin, that’s not likely to find its footing anytime soon.

Or maybe, you’re on the other end, and you’d prefer the simplicity of non-recursive like OP_CTV or OP_VAULT. Non-recursive covenants are simpler and easier to reason about, without the risk of creating an uncontrolled chain of constraints.

What if some version of recursive covenants were inevitable?

Over the years, developers have noticed that almost any extension to the transaction validation logic could be used to emulate the functionality of OP_CAT.

In the Script universe, there are two realms, based on the size of the stack elements. For stack elements larger than 4 bytes, you can compare for equality, interpret as a key a signature, or hash it. For stack elements less than or equal to 4 bytes, you can treat them as objects to do arithmetic or branching. With a RISC-V processor running on a BitVM, you can do literally anything. Anything that allows you to emulate OP_CAT, break stack elements up, or concatenate them together brings these two realms together, so that you can ‘do anything’ with Script.

Researchers like Andrew Poelstra expect we could do recursive covenants with pretty much any new opcode. If true, that would be a justification for working towards a way to do them well.

Is OP_CAT the likely path forward for covenants?

If covenants are not just interesting, but inevitable, how do we ensure it’s implemented in such a way that gets more Bitcoin users sending trustlessly like Satoshi originally envisioned? While ossificationists remain divided, still OP_CAT continues to ascend as a strong contender in the covenants debate.

OP_CAT is not the most elegant chisel, but it’s one with the best ratio of power to complexity, that would allow developers to carve up some amazing new features.

This is a guest post by Kiara Bickers. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

MicroStrategy, a leading enterprise business intelligence firm that has emerged as a pioneering Bitcoin advocate among public companies, is hosting its Bitcoin For Corporations conference starting today. The event is taking place May 1 – May 2, 2024 in Las Vegas, NV will feature industry leaders discussing how corporations can adopt Bitcoin as a treasury asset.

MicroStrategy has bought over 1% of the total Bitcoin supply since first purchasing BTC in 2020. The company recently added 122 more bitcoins in April, now holding an astonishing 214,400 BTC worth billions. Its Bitcoin strategy has multiplied MicroStrategy’s enterprise value and blazed a trail for corporate Bitcoin adoption.

Accordingly, the company is hosting an educational Bitcoin conference tailored towards other major corporations. Streamed live on Bitcoin Magazine’s YouTube channel and X, sessions will cover the case for Bitcoin as a corporate treasury asset and strategy insights from MicroStrategy’s journey.

MicroStrategy CEO Michael Saylor is slated to speak on various topics around BTC for corporations. Other speakers include Galaxy Digital’s Head of Research, Alex Thorn, Bitwise’s Senior Crypto Research Analyst, Ryan Rasmussen, and Citibank’s Head of Digital Assets, among other industry leaders.

River Financial CEO Alex Leishman will discuss Bitcoin adoption trends. Lightspark CEO David Marcus, who helped Coinbase integrate Lightning, will join Michael Saylor to talk about “Building on Bitcoin.” Fidelity Digital Assets’ Chris Kuiper and MicroStrategy’s Shirish Jajodia will share a panel on “Bitcoin and Wall Street.”

The lineup of executives from major financial institutions signals growing corporate interest in Bitcoin exposure. As pioneering firms like MicroStrategy and Tesla reap the benefits, others seem poised to follow.

Conferences like this provide a venue for education and idea sharing as more corporations consider adding Bitcoin to their balance sheet.

The overall event is projected to exceed 1,000 executives in attendance, including representatives from Microsoft, Amazon Web Services, Google Cloud, Bayer, Bank of America and Hilton.

The Bitcoin Magazine livestream of Bitcoin for Corporations will be broadcast on X, YouTube, Facebook and LinkedIn from today, from today, starting at 4:30 PM.

Major global bank Standard Chartered believes the Bitcoin price could see further downside to around $50,000, according to recent comments.

Geoffrey Kendrick, head of forex and digital assets research at Standard Chartered, told The Block: “BTC’s proper break below $60,000 has now reopened a route to the $50,000-52,000 range.”

As of writing, Bitcoin is trading under $57,000 after a steep drawdown from recent highs above $70,000. Kendrick cited both the Bitcoin market and broader macroeconomic factors weighing on Bitcoin’s price.

He highlighted five straight days of outflows from U.S. spot Bitcoin ETFs and the slow start for new Hong Kong spot Bitcoin ETFs as the reasons for the recent drawdown.

Beyond markets, Kendrick pointed to deteriorating liquidity measures in the U.S. that have put pressure on risk assets like Bitcoin.

However, Standard Chartered and Kendrick maintain a bullish long-term outlook. The bank recently raised its 2024 year-end Bitcoin price target to $150,000 and sees prices potentially reaching $250,000 in 2025.

Kendrick stated the bank’s forecast remains intact, expecting the next rally to come after the 2024 U.S. elections.

Negative sentiment stemming from the recent arrests of Binance founder Changpeng Zhao (CZ) and early Bitcoin investor Roger Ver could also be factors in the drawdown.

Click the image to learn more.

Still, the pullback also comes after Bitcoin posted seven straight months of gains, signaling a potential need for consolidation.

However, mainstream adoption continues accelerating, as seen in the massive early inflows into U.S. spot ETFs. And while Hong Kong ETF trading began slowly, these investment vehicles should unlock significant institutional demand over time.

Hoseki, a leader in Bitcoin and blockchain verification solutions, has unveiled Hoseki Verified, a new verification product aimed at enhancing transparency and trust in the cryptocurrency industry, with a focus on spot Bitcoin exchange-traded fund (ETF) asset verification, according to a press release sent to Bitcoin Magazine.

This public dashboard aims to set a new industry standard for verification, offering both retail and institutional investors full visibility into the BTC holdings of these funds.

Image via press release

Hoseki Verified intends to provide real-time verification of bitcoin held in custody by spot Bitcoin ETF issuers and other financial institutions. The public dashboard, accessible to all, displays verified bitcoin holdings with custodians such as Coinbase, BitGo, and Gemini, according to the release, offering a level of transparency previously unavailable in the industry.

“In the world of institutional investing, transparency isn’t just a value-add; it’s a fundamental necessity,” said Hoseki CEO Sam Abbassi. “As the crypto market matures, investors demand higher standards of clarity and accountability. Hoseki Verified meets this need by providing an unwavering level of digital asset verification, ensuring that every Spot Bitcoin ETF adheres to the highest standards of transparency and integrity.”

Asset management firm and spot Bitcoin ETF issuer Bitwise (BITB), has embraced this initiative as the first participant. In January, Bitwise first provided transparency regarding its Bitcoin ETF when it published the bitcoin addresses of its ETF holdings, taking lead in setting a new precedent for asset transparency amongst the ETF issuers. By partnering with Hoseki Verified, Bitwise is reinforcing its dedication to investor confidence and security.

“We deeply care about Bitcoin and its core value propositions, amongst them being audibility and public transparency, which is why we’ve taken the initiative in being public about our on-chain assets and why we are thrilled to be working with Hoseki to make the public transparency work we’ve already done even more robust,” explained Bitwise CTO Hong Kim.

Hoseki Verified is not just limited to Bitwise; it welcomes and invites other entities in Bitcoin to join this initiative to create a more transparent Bitcoin investment landscape. With Hoseki Verified, investors can verify the integrity and transparency of these investment vehicles, ultimately contributing to a healthier and more trustworthy financial ecosystem.