Welcome to this week’s Weekly Development Report, highlighting continued progress across the ecosystem, with a focus on reliability, security, and improving the underlying infrastructure. This week, Mainsail received further improvements to native contract events, API resource management, and transaction-pool resilience, while ARK Scan saw updates to search configuration, forging statistics, and delegate monitoring. We also completed a broader round of dependency and server infrastructure updates, bringing our applications and environments up to date with the latest security patches and software releases.
Development Activity Summary (November 06 – November 13, 2026)
Below is a breakdown of the total number of merged commits and contributing authors by project, highlighting development activity from November 06, 2026, to November 13, 2026.
| Project | Commits | Authors |
|---|---|---|
| ARK Connect | 0 | 0 |
| ARK Scan | 7 | 2 |
| ARK SDKs & Docs | 0 | 0 |
| ARK Vault | 0 | 0 |
| Mainsail | 122 | 2 |
In total, 129 commits were merged across all projects this week. As always, commit counts fluctuate with sprint focus and task complexity.
ARK Scan Weekly Report
This week’s ARK Scan work focused on improving search configuration, addressing forging statistics inconsistencies, and making the delegate monitor more reliable when blocks are missed.
Search configuration was updated to support the SCOUT_PREFIX environment variable. Previously, search index names were hardcoded, preventing deployments from using custom prefixes. The changes now allow index names to follow the configured prefix, making the search setup more flexible across environments.
A reliability issue affecting the forging statistics command was also addressed. The BuildForgingStatsTest occasionally failed in CI because the expected number of forging statistics varied depending on the generated test data. Block ordering was adjusted when calculating missed blocks to ensure the statistics are processed consistently and the test results are more deterministic.
Further fixes were made to the delegate monitor and missed-block handling. With the introduction of WebSocket updates, the monitor could fail to refresh when a block event was missed, leaving the displayed data outdated. The refresh logic was improved to account for missed events and keep the monitor up to date. An additional fix addressed cases where missed blocks were not associated with a validator, which previously caused the missed-blocks page to fail to load.
Next week, we’ll continue internal testing of ARK Scan, address any remaining issues with the delegate monitor and forging statistics, and work through the planned dependency updates to keep the application aligned with the latest versions.
Mainsail Weekly Report
This week’s Mainsail work focused on expanding native contract event support, improving API resource management, and strengthening transaction-pool reliability.
New contract events were introduced to provide updates on validator and wallet activity. The events cover validator registration, updates and resignation, wallet voting and unvoting, as well as username registration and resignation. Each event is emitted at most once per block and includes the block number, relevant addresses, and associated entries.
JSON-RPC batch responses now have a default size limit of 25 MB to prevent excessively large responses from placing unnecessary pressure on the API. When the limit is exceeded, additional items return a -32003 Response too large error. The limit can be adjusted through the MAINSAIL_API_EVM_BATCH_RESPONSE_MAX_SIZE environment variable or disabled entirely by setting it to 0.
The transaction-pool API received several improvements to request handling and pagination. Unconfirmed transaction listings are now limited to 1 MB of JSON per response while always returning at least one transaction. When a response reaches the size limit, pagination continues from the correct offset through meta.next, preventing transactions from being skipped. The response retains its existing data structure, and offset-based requests are now supported.
Two new API plugins were also introduced to manage concurrent requests. The global concurrency limit restricts the number of requests being processed across all clients and returns a 503 response when capacity is reached. The per-IP limit applies a separate cap to each client and returns 429 when exceeded, while allowing whitelisted IPs to bypass the restriction. Both limits can be disabled independently. The transaction-pool API now applies these protections to both unconfirmed transaction listing routes, allowing up to 16 concurrent requests overall and four per IP. Other routes, including transaction submission and configuration endpoints, remain unaffected.
Finally, the transaction-pool worker was updated to recover automatically after a crash by respawning the worker instead of shutting down the entire node. This improves resilience and helps prevent individual worker failures from interrupting node operation.
Next week, we’ll continue the P2P development work by replacing Hapi with a custom server, with a focus on completing the migration, addressing compatibility and connection-handling issues, and refining the surrounding networking components. We’ll also continue testing the recent API and transaction-pool changes to ensure they perform reliably under different workloads.
Infrastructure & Security Updates
Over the past months, the number of reported security vulnerabilities across commonly used software packages has risen noticeably. New issues surface regularly in libraries, frameworks, and system tools that power applications all over the web. Even though many of these vulnerabilities don’t affect our setups directly, they were a good reason for us to take a critical look at our own infrastructure and the apps running on it.
We have been updating our projects over the past weeks to bring their dependencies up to the latest versions wherever possible. Besides closing known security gaps, this also gives us access to performance improvements, bug fixes, and longer support windows, and it makes future updates smaller and easier to manage.
Updates don’t stop there, as the projects also run in an environment which can become outdated. Therefore we reviewed the software stack on our servers, including operating system, language runtimes, and databases. Where needed we upgraded to the latest releases to ensure everything is up to date with the latest security patches.
For some of the projects, upgrading in place wasn’t the best approach. In those cases we set up new servers with a fresh, current configuration in parallel. By preparing and testing each environment before switching traffic, we were able to complete these migrations without any downtime for our users.
Security remains an ongoing process. With these updates in place, our infrastructure is on a solid, modern foundation, and we’ll continue to keep a close eye on new vulnerabilities and regularly update both our projects and servers going forward.
Feedback & Feature Requests
If you are using our open-source products and would like to provide feedback or request a feature, please feel free to contact us via the contact pages for the specific product you are using or open an issue on GitHub.
Quick access links to GitHub issues pages:
Follow Us on X
Follow us on X and keep an eye on the blog to stay up to date with everything we ship. We publish a development report every week so you can follow along as the ecosystem grows.
