Q&A with the ARK Team.

In Q4 2025, I sent the team a list of questions about the brand-new ARK codebase currently in development. I knew full well that dropping questions during the holidays, right in the middle of end-of-year coding sprints, would likely mean a delay in responses. Still, it felt important to get them into the queue before something else inevitably pushed them even further down the line.

That turned out to be a smart move. Here we are at the start of Q1 2026, and the answers are just now coming in. Throughout that entire window, the team kept me informed about timelines and workload, which I genuinely appreciate. So, thank you to the team for taking the time to respond—and a special thanks to Rok Černec for keeping me in the loop along the way.

For those new to ARK, or for anyone not fully up to speed on what this new codebase is and why it matters, I’d recommend starting with my previous article on Mainsail over on the Strake Blog. It breaks things down in a way that’s approachable even if you’re not deeply technical, and it’s well worth the read.

Originally, I sent over 20 questions with optimistic hopes that each could be addressed. I also understood that, given regulatory considerations tied to the organization and its jurisdiction, some topics might be off-limits. With that in mind, I’m happy to report that 13 of those questions were answered, and answered in meaningful detail.

This article will lean more technical, and toward the end I’ll also touch on the questions that couldn’t be addressed. With that, let’s get into the Q&A.

Q: A large reason for Mainsail was to fix block finality for ARK Core. Can you explain some of the biggest issues that had to be tackled to achieve instant finality for Mainsail, what major changes needed to be made and why block finality is so important?

A: In the past, several attempts have been made to try to fix the ARK Core consensus. But none succeeded, so we rebuilt the consensus entirely from scratch for Mainsail to address all shortcomings and achieve instant finality. Forks, rollbacks, etc., which most should be familiar with from ARK, are a thing of the past in Mainsail. Once a block has been accepted, it cannot be reverted. It is final forever.

This is achieved via Mainsail’s own Byzantine Fault Tolerant (BFT) inspired consensus, which differentiates between three phases: the block proposal, prevote and precommit. All of these phases happen at each block and require the participation of the majority of validators. This puts a high burden on the P2P layer, which has to process many messages in a short amount of time. Performing expensive signature aggregation and validation all in under 8 seconds required a lot of optimizations under the hood.

Instant finality has many benefits. One being that without reverts/rollbacks/forks, a lot of assumptions are simplified. For example, it made the EVM integration a lot easier since we do not have to worry about having to handle transaction reverts. However, the most important reason is that it vastly improves network security over ARK Core.

Q: With Mainsail, we see the number of forging validators increased from 51 to 53. In the past, there were heavy discussions involving the need for it to be a prime number. Can you go over the importance of this change and the technical need for this increase?

A: In most BFT-style systems, the validator count isn’t arbitrary; it’s chosen to hit specific safety and liveness thresholds while still keeping the network efficient and reasonably decentralized.

Classical Byzantine Fault Tolerant consensus uses the well-known bound:

N = 3f + 1

• N = total validators in the committee

• f = maximum number of Byzantine (faulty/malicious) validators the system can tolerate

This relationship is what guarantees you can still reach an agreement even if up to f validators behave arbitrarily.

With 51 validators, the largest f that satisfies the bound is:

• 51 ≥ 3f + 1 → f = 16 (since 3·16 + 1 = 49, but 3·17 + 1 = 52 would exceed 51)

With 53 validators:

• 53 ≥ 3f + 1 → f = 17 (because 3·17 + 1 = 52, and 53 is safely above that minimum)

So the upgrade from 51 → 53 increases fault tolerance by one full Byzantine validator:

• 51 → f = 16

• 53 → f = 17

That’s a meaningful jump: roughly +6% more adversarial tolerance for roughly +4% more validators.

In BFT systems, a typical commit/finality quorum is:

2f + 1

So the quorum threshold shifts upward accordingly:

• for f = 16 → quorum = 33

• for f = 17 → quorum = 35

This makes it harder for an attacker to stall or influence decisions, and it reduces “knife-edge” scenarios where the system is operating right at the minimum margin.

There used to be a discussion about prime validator counts, but from a BFT correctness standpoint, primality isn’t a technical requirement. What actually matters is meeting the 3f + 1 bound and having clean quorum behavior.

Many systems prefer an odd-sized committee because it avoids awkward ties in simple majority reasoning and tends to reduce edge-case complexity around voting thresholds and coordination. In this case, 52 is the minimum for f = 17, and moving to 53 keeps the committee odd while preserving the same fault-tolerance class.

Moving to 53 forging validators is primarily about hitting the next BFT safety tier:

• upgrades tolerated Byzantine faults from 16 → 17

• raises typical quorum from 33 → 35

• keeps the committee odd, which simplifies majority semantics and avoids certain liveness/voting edge cases

It’s a small increase in committee size that buys a disproportionate increase in resilience.

Q: Touching back on the total validator increase to 53, do you see an inflation issue persisting with the extra increased ARK created per round?

A: Short answer: No, increasing the forging validator set to 53 does not create additional inflation.

While a single round will include a couple more blocks (and therefore a bit more ARK forged per round), the key point is that a round also takes proportionally longer, because there are more validators taking turns forging.

What drives emission is time, not the round structure:

• Block time stays 8 seconds

• Block reward stays 2 ARK

So the network still produces the same number of blocks per hour/day/year, and therefore the total ARK created per day and per year remains unchanged. In other words, inflation is time-based, not round-based, and the validator-count change only affects how blocks are grouped into rounds, not how fast new ARK is forged/minted over time.

Q: Will there be a stress test for the Mainsail testnet in the near future, and will the scripts/tooling be publicly available for testers?

A: Yes, there will be additional and larger stress tests for the Mainsail testnet in the near future. As most core features are now complete or nearing completion, we’ll be shifting more focus toward targeted testing and broader stress testing to validate performance, stability, and edge cases under heavier load.

Alongside this, we’ve been continuously extending and improving the existing Mainsail TX Tester script. With each new feature and iteration, the script is updated to support new transaction types and testing scenarios. These tools are intended to be publicly available, making it easier for community members to participate in testing, reproduce specific cases, and contribute meaningful feedback. The goal is to lower the barrier to entry for testers while enabling more comprehensive and realistic test coverage across the network.

Q: How do you currently plan on rolling out the Mainsail update? Could it potentially be a more centralized rollout using genesis validators and timelocks to slowly allow public validators into forging over a period of time?

A: The Mainsail rollout is planned to follow the same model used for the Mainsail Public Testnet, rather than a staged or permissioned rollout that gradually opens forging.

There will first be a preparation phase on the current V3 Mainnet, during which ARK Core delegates must register a BLS public key on-chain using a dedicated transaction type (the same mechanism previously used on Devnet). This ensures that validators are cryptographically ready to participate in the new consensus from day one.

Once this registration window closes, at a predefined block height, a snapshot of V3 Mainnet will be taken. That snapshot is then used to construct the Mainsail Mainnet genesis block.

Any delegate that has successfully registered a BLS key by that point becomes a genesis validator and participates in bootstrapping the Mainsail network immediately. The network will only start if a sufficient number of validators are ready and actively participating in the new consensus.

This approach avoids gradual gatekeeping or time-locked admission. Instead, it provides a clean, deterministic transition where participation is open to all existing delegates who meet the technical requirements.

Exact parameters and timelines will be shared closer to the Mainsail Mainnet launch.

Q: I know in the past it was always the team philosophy to not be involved in voting for validators of any kind or be involved in any kind of favoritism towards one validator or another, but have you since contemplated the possibility or real need to potentially have to vote for a validator to assist in a major upgrade effort?

A: With this upgrade, existing votes will carry over, so neither validators nor voters need to take action to keep their current voting positions through the transition, aside from validators completing the required BLS key registration to actively participate under the new governance/consensus rules.

More broadly, our stance hasn’t changed. We remain impartial and do not vote for, endorse, or promote any specific validator. Major upgrades are designed to be executed through the protocol rules and validator coordination, not by the team stepping in to influence governance outcomes or create favoritism.

If an upgrade ever required extra coordination from the community, our role would be to provide clear communication, tooling, and technical support, not to cast votes as a way to steer validator selection.

Q: Will the addressing system change in Mainsail require users to swap to a new ARK coin? Also, if this were to happen, would the swap ratio remain 1:1 and would it happen automatically or would it be manual?

A: No, the Mainsail addressing changes do not require users to swap to a new ARK coin.

Mainsail Mainnet will be bootstrapped from a snapshot of the existing ARK Core chain, meaning all balances and accounts are carried over directly. Users will be able to access their funds on Mainsail using the same passphrase they already have. Internally, these are referred to as legacy wallets, but from a user perspective, they behave just like any other wallet.

Because of this, there is no manual migration, no opt-in process, and no swap mechanics involved. Nothing needs to be converted or claimed.

The only user-visible change is the unit precision: ARK moves from 8 decimal places (ARKTOSHI) to 18 decimals (WEI). This is a purely technical change for higher precision and does not affect balances or value, ownership and amounts remain fully intact.

Q: With the addressing system change from ARK core to Mainsail, will users be required to reissue validator votes after the update? Also, would validators need to re-register their usernames?

A: No, users will not need to reissue validator votes after the update, and validators will not need to re-register their usernames.

The migration snapshot preserves the current on-chain state, including all existing votes and registered usernames.

Q: Will transaction history be preserved after the Mainsail upgrade, and will it all be accessible via the block explorer?

A: Yes, transaction history will be fully preserved after the Mainsail upgrade.

Mainsail is a hard fork and represents the largest upgrade to the ARK ecosystem so far, but it does not erase or discard any historical blockchain data.

• All blocks and transactions before the Mainsail fork remain intact and can be accessed via a legacy ARK blockchain explorer (legacy ARK Scan).

• All blocks and transactions after the fork will be indexed and available on the new ARK blockchain explorer (updated ARK Scan).

In short, the blockchain history is continuous, with full transparency across both explorers. Users will have complete visibility into the ARK blockchain both before and after the upgrade, ensuring no data is lost.

Q: In the past, the team partnered with a large development analysis company to go over the codebase and implement a bug bounty program. Are there any plans to issue a bounty program similar to that or at least bring in a 3rd party to go over the Mainsail code?

A: Yes, security and code quality are a high priority for Mainsail, and we do plan to engage a third-party auditor as part of the process. Given the scope and significance of the Mainsail upgrade, it’s expected that an external audit will be brought in to independently review the codebase, validate assumptions, and help identify potential issues that may not surface through internal testing alone.

In addition to internal reviews and extensive testnet activity, third-party audits provide an extra layer of assurance around protocol logic, consensus changes, and new features introduced with Mainsail.

Overall, the goal is to combine internal expertise, community testing, and independent external validation to ensure Mainsail is robust, secure, and production-ready before mainnet activation.

Q: Can you share the current internal timeline for the full Mainsail upgrade to mainnet? I know this can change at any time for a variety of reasons, but I am curious if there is a current goal at least.

A: At this stage, there isn’t a fixed timeline that we’re ready to share for the full Mainsail upgrade to mainnet. Given the size and scope of the upgrade, the focus is intentionally on milestones rather than dates.

The current focus is on finalizing the remaining features and addressing reported issues. Once that phase is complete, attention will move toward comprehensive testing, including targeted test scenarios, larger-scale stress testing on testnet, and iterative improvements driven by feedback and results. In parallel, internal reviews and third-party audits will be carried out to ensure the protocol meets the required standards for security, stability, and mainnet readiness.

Only once these phases are successfully completed would a mainnet upgrade be considered. While timelines can and do change, the overarching goal is to prioritize correctness, security, and network stability over speed.

Q: Many people do not realize how monumental this upgrade is and how many things and moving parts need to change. Can you give a quick overhead view explanation of some of the changes that were needed to be made including wallets, explorer, etc..?

A: From the outside, this upgrade can look like “just” a new release. In reality, it’s closer to swapping an engine while the car is still moving. Mainsail isn’t a small iteration on the existing stack; it introduces a new execution environment, new standards for addresses and transactions, and new expectations for ecosystem tooling. That means core infrastructure and every product that touches it (wallets, explorers, APIs, SDKs, and hardware support) needed significant updates. Here are some of the key changes across the ecosystem:

• A new execution layer: REVM (Rust EVM) integration
  Mainsail is no longer a pure TypeScript codebase. To support performant EVM interoperability, the stack now includes substantial Rust components via revm (Rust EVM). This is a foundational change: it affects runtime behavior, performance characteristics, and how tooling interfaces with execution.

• A new address standard (ARK Base58 → Ethereum-style Keccak256)
  The address scheme moved from Base58 (ARK-style) to Keccak256 (Ethereum-style) addressing. That change ripples everywhere: wallets must display and validate different address formats, explorers must index and search differently, and APIs/SDKs must treat addresses according to EVM conventions.

• Transactions re-architected around smart contracts, not transaction “types”
  Instead of handling actions through distinct transaction types, key network behaviors are now implemented through smart contracts (e.g., Usernames, Validator Registration, Voting, Consensus, and more). This required a major overhaul of transaction flow and business logic across products, including how transactions are built, signed, broadcast, interpreted, and displayed.

• Legacy wallet continuity through snapshot support
  To avoid leaving existing users behind, legacy wallet support is provided through a snapshot mechanism. This enables continuity for historical balances and state while moving forward on the new system, without forcing a full “hard break” from prior data.

• Better interoperability with third-party EVM wallets
  Supporting wallets like MetaMask and Rabby isn’t plug-and-play; it requires additional tooling and compatibility layers so external wallets can connect, sign, and interact reliably. This expands access and usability, but also introduces new technical requirements around standards and expectations in the EVM ecosystem.

• Major API changes for EVM compatibility and new features
  EVM support and compatibility required substantial API additions and changes. Explorers, wallets, indexers, and integrators rely heavily on these APIs so changes here are both deep (data models, endpoints, behaviors) and broad (every downstream consumer needs updates).

• Ledger hardware wallet support updates
  Hardware wallet support, Ledger, needed changes to account for the new address scheme, signing flows, and transaction construction. Hardware devices are strict about formats and derivation paths, so compatibility work here is critical (and often non-trivial).

• SDKs refactored for the new world
  With new addressing, smart-contract-driven transaction logic, and expanded API surface area, the SDKs needed a refactor to provide clean developer ergonomics and reliable integrations. That includes building and signing flows, compatibility helpers, and updated abstractions for the new architecture.

Q: After this large upgrade, are there any plans to focus on building on top of ARK? Possibly expanding the ecosystem with more useful tools and apps?

A: Yes, absolutely. Once the Mainsail upgrade is complete, a stronger focus will shift toward building on top of ARK and expanding the broader ecosystem. Mainsail is designed to provide a more flexible and powerful foundation, which opens the door for more useful tools, applications, and developer-facing infrastructure to be built around the network.

In parallel, the team remains open to ideas and contributions from the community. Community-driven proposals, tools, and applications are encouraged, as long as they align with ARK’s overall mission and long-term vision. The goal is to foster a healthy ecosystem where both internal development and community innovation can thrive on top of a more robust core protocol.

Now let’s cover some questions the team did not answer due to redundancy or regulatory reasons as I attempt to offer my opinions on them. Again, these questions were unanswered and for good reason, but I am adding them here to show everyone that asking these questions in public or private most likely won’t be answered and these are the reasons I believe this to be true. My responses here are not just an opinion of an outsider looking in, they are of one that was on the inside for much of ARK’s existence.

1. Has the team discussed potentially reducing forging rewards over time similar to the bitcoin halving cycle?

We can see there are no plans for this and all concerns over inflation over time have been addressed in a previous question above.

2. With Mainsail being EVM compatible now, are you in talks with any teams to potentially build on, or migrate to ARK in the near future?

This was broadly covered in the final question answered, but from previous experience over the years we can extrapolate that they would not share potential partnerships until both parties are ready to go public with that information.

3. Knowing that ARK incubated the Protokol consulting and dev company, will they be involved with or working to build anything on ARK in the near future?

This question does not involve the ARK devs and should be directed towards the Protokol company, so it would make sense that the devs could not answer this question.

4. Will there be a stress test for the Mainsail testnet in the near future, and will the scripts/tooling be publicly available for testers?

This question was answered above and is redundant.

5. There is currently an active whale with a large majority of validators on the network. Do you see any potential network centralization issues arising from this entity in the near future?

The team has been very clear that they will not participate in validator voting dynamics or engage in discussions around centralization at the governance level. Their focus remains strictly on delivering a decentralized protocol and robust codebase, rather than influencing how network participants choose to operate on top of it.

6. Some have voiced concerns about the private whale validators potentially taking over the network and centralizing ARK completely. Has the team discussed internally how to potentially mitigate this effect during the update process?

Ya, I tried to reword a few questions in an attempt to get something, but to no avail as the team has made themselves very clear regarding voting and validators.

7. Here is the dreaded marketing question. Does the executive team plan on building out a marketing strategy of some type to push the new ARK features to the world outside our currently small ecosystem?

This question has surfaced many times over the years, and frankly, it’s understandable why the team has historically chosen not to engage with it directly. Speaking from experience as a former co-founder, I’ve had firsthand visibility into partnerships and marketing strategies, and these are not topics that lend themselves well to public play-by-play.

There’s an inherent tension here: the community quite reasonably wants a decentralized, open-source project to be fully transparent, while at the same time the ARK business entity is a private organization with no obligation, or incentive, to disclose sensitive strategic details. Based on my prior role, there are two primary factors that have consistently shaped this approach.

First, marketing strategy is a closely guarded asset. Releasing plans prematurely invites front-running, imitation, or deliberate attempts to undermine a campaign before it ever has a chance to generate meaningful data or return on investment. In short, if everyone knows the playbook before kickoff, the play rarely works.

Second, and more importantly, there are jurisdictional realities. The ARK business entity is registered in Paris, France, and operates under strict French and EU regulatory frameworks. These regulations explicitly limit how cryptocurrency projects may discuss, promote, or otherwise influence their coins or tokens. This includes traditional marketing efforts, exchange-related campaigns, market-making activities, and similar initiatives. Compliance here isn’t optional, it’s foundational.

What is permitted, however, is promotion of the technology itself: the codebase, the protocol, and the products that can be built on top of it. That distinction still leaves meaningful room for marketing, but it looks different from what many crypto-native users might expect. The focus shifts toward developer adoption, real-world use cases, product ecosystems and brand awareness, rather than direct promotion of the ARK coin.

In other words, the door isn’t closed on marketing. It’s simply pointed in a direction that prioritizes compliance, sustainability, and long-term value over short-term hype.

8. We have seen some recent large airdrops in our industry that turned unheard of platforms and companies into million user mainstream players. Are there any plans to make an airdrop initiative to drive marketing and hype and potentially gain a large new user base in the process when launching Mainsail?

This question closely mirrors those above, and for similar reasons, it’s not something the team can comment on in detail. While airdrops have proven to be an effective growth and awareness tool across parts of the industry, they also introduce significant legal and regulatory complexity—particularly when operating across multiple jurisdictions with differing interpretations and enforcement frameworks. Given these considerations, especially within certain regulatory environments, an initiative of this nature is not currently planned and is unlikely to be pursued.

Well, that’s the Q & A. Thank you for reading. I hope this Q & A session answered some lingering questions you may have had and maybe you learned something new. If you enjoyed this article and want to continue to see more, please vote for our validator securing the ARK network. Voting for our validator does not lock your ARK, but it does pay you staking rewards automatically every day. See here for more info and an easy walkthrough on how to vote/stake for the strakefoundation validator.

Follow Strake on X and in Discord to get updates about ARK and more.

Disclaimer time. This article was put together using official ARK Team responses to questions sent in, anything outside of quoted text from official sources is strictly the opinion of The Strake Foundation. If you like these articles and reviews we would appreciate a vote for our ARK validator, delegate strakefoundation, to help us continue to inform and support the ARK community. If you would like to learn more about ARK, ARK governance and validator/delegate voting and staking, please read our complete ARK Staking Guide.