Adani Group to Acquire Europe's No. 2 Liquid Storage Operator Evos B.V. for €2.56 Bn

In one of the most significant overseas acquisitions by an Indian infrastructure company, Adani Ports and Special Economic Zone Limited (APSEZ), has agreed to acquire 100% of Netherlands-headquartered Evos B.V., Europe’s second-largest independent liquid storage operator, for an enterprise value of €2.56 billion. The all-cash transaction represents far more than a simple expansion of APSEZ’s international footprint. It signals the company’s growing ambition to become a global transport, logistics and energy infrastructure powerhouse.

The acquisition strengthens APSEZ’s presence across critical European energy and industrial corridors while providing access to a highly profitable liquid storage business that serves traditional fuels as well as emerging energy-transition products.

A Transformational International Expansion

Under the agreement, APSEZ will acquire the entire stake in Evos from Igneo Infrastructure Partners. The transaction values Evos at an equity value of €1.18 billion and implies an acquisition multiple of 11.7 times CY25 EBITDA.

For APSEZ, the deal represents a major step towards building a truly global integrated transport platform. Following the acquisition, the company's international footprint will expand to 28 ports and terminals across 10 countries, significantly increasing its geographic diversification and reducing concentration risk.

The transaction remains subject to regulatory approvals and works council consultation processes in Europe and will be funded through debt.

Why Evos Matters

Evos occupies a strategically important position in Europe's energy logistics infrastructure.

The company operates eight port-based liquid storage terminals across the Netherlands, Germany, Belgium, Spain and Malta, with a combined storage capacity of 6.3 million cubic metres. These facilities are located in some of Europe's most significant energy and industrial hubs, including the Amsterdam-Rotterdam-Antwerp (ARA) region, Hamburg and key Mediterranean trade gateways.

The platform includes 452 storage tanks, 63 vessel and barge berths, as well as extensive pipeline connectivity, including links to Schiphol Airport and the Central Europe Pipeline System.

This infrastructure serves a broad customer base comprising energy companies, industrial firms, chemical manufacturers and commodity traders. The diversity of customers and products gives Evos a resilient business model that is less exposed to fluctuations in any single market segment.

Strong Financial Fundamentals

A key attraction for APSEZ is Evos' robust financial profile.

For calendar year 2025, Evos generated revenue of €392 million and EBITDA of €219 million, translating into an EBITDA margin of 56%. The terminals handled approximately 37 million metric tonnes of throughput during the year.

The business also maintains exceptionally high operational utilisation, with average commercial occupancy of 99%. A substantial portion of revenues is secured through take-or-pay contracts and agreements indexed to inflation, providing predictable cash flows and protection against economic volatility.

For investors, these characteristics make Evos a highly defensive infrastructure asset capable of generating stable returns across business cycles.

Positioning for the Energy Transition

Perhaps the most strategically important aspect of the acquisition is Evos' role in Europe's evolving energy landscape.

While the company continues to handle traditional petroleum products such as gasoline, gasoil, marine fuels and jet fuel, it has also developed infrastructure supporting transition fuels including sustainable aviation fuel (SAF), biofuels, methanol and bioethanol.

Europe remains at the forefront of global decarbonisation efforts, driving investment into alternative fuels and cleaner energy supply chains. By securing ownership of critical storage and handling infrastructure, APSEZ gains exposure to long-term growth opportunities linked to the continent's energy transition.

The acquisition therefore offers APSEZ a dual advantage: continued participation in established fuel markets while positioning itself to benefit from emerging low-carbon energy ecosystems.

Strategic Benefits for APSEZ

Geographic Diversification

The acquisition significantly strengthens APSEZ's international platform by adding assets across multiple European countries. This diversification reduces dependence on any single economy, market or regulatory environment.

Expansion into High-Margin Storage Infrastructure

Storage infrastructure generally offers more stable earnings than traditional port operations due to long-term contracts and recurring customer relationships. Evos' 56% EBITDA margin highlights the attractiveness of this business model.

Entry into European Energy Corridors

The terminals provide access to some of Europe's most critical import, export and distribution hubs, strengthening APSEZ's role in global trade and logistics networks.

Enhanced Risk Profile

According to APSEZ, the transaction will improve the scale, geographic diversity and cash-flow characteristics of the combined platform, thereby strengthening its overall business risk profile.

Financial Impact

Following the acquisition, APSEZ expects the combined entity's pro forma net debt-to-EBITDA ratio to be approximately 2.76x based on APSEZ FY26 and Evos CY25 financials. The company expects this leverage level to improve to around 2.5x by FY27.

These figures suggest that while the acquisition is substantial in scale, management remains focused on maintaining financial discipline and balance-sheet strength.

Industry Implications

The acquisition reflects a broader trend among global infrastructure operators seeking ownership of strategic logistics and energy assets outside their home markets.

As supply chains become increasingly interconnected and geopolitical uncertainties reshape trade routes, ownership of critical infrastructure across multiple geographies is emerging as a key competitive advantage. APSEZ's move mirrors this global trend and positions the company alongside major international infrastructure operators managing diversified portfolios across continents.

The transaction also underscores the growing confidence of Indian multinational companies in pursuing large-scale acquisitions in developed markets, particularly in sectors linked to logistics, transportation and energy security.

Outlook

With the acquisition of Evos, APSEZ is not merely adding storage capacity; it is securing a strategic foothold in Europe's energy infrastructure ecosystem. The deal combines stable cash-generating assets, exposure to energy-transition growth opportunities and access to some of the world's most important trade and industrial corridors.

As global energy flows continue to evolve and supply chains become more integrated, APSEZ's purchase of Evos may be remembered as a defining transaction in its transformation from India's largest private port operator into a genuinely global logistics and infrastructure enterprise.

India Approves 12 New Electronics Manufacturing Projects, Launches Semicon 2.0 Portal

The Indian government has approved 12 new projects under the ₹40,000 crore Electronics Component Manufacturing Scheme (ECMS), taking the total number of approved projects under the scheme to 118.

The newly cleared projects are expected to generate production worth ₹39,045 crore and create 7,127 direct jobs.

Key Highlights of the New ECMS Approvals

• 12 new projects approved under the Electronics Component Manufacturing Scheme (ECMS).
• Total approved projects rise to 118.
• Expected production value: ₹39,045 crore.
• Expected direct employment: 7,127 jobs.

States Covered by the Projects

According to the Ministry of Electronics and Information Technology (MeitY), the projects are spread across:

• Gujarat
• Karnataka
• Madhya Pradesh
• Maharashtra
• Punjab
• Tamil Nadu
• Uttar Pradesh

Components to be Manufactured

• Copper foil
• Cathode active materials
• Speciality ceramics
• Multilayer printed circuit boards (PCBs)
• Relays
• Heat sinks

Government Launches ISM 2.0 Portal

Alongside the approvals, Union Electronics and IT Minister Ashwini Vaishnaw launched the application portal for India Semiconductor Mission (ISM) 2.0, also known as Semicon 2.0.

The programme has a fiscal outlay of ₹1.27 lakh crore and aims to strengthen India's semiconductor ecosystem through six strategic pillars, including chip design, equipment and materials, fabrication facilities, packaging, research & development, and talent development.

Applications Invited Under ISM 2.0

• Semiconductor equipment and materials units
• New semiconductor fabrication plants (fabs)
• Semiconductor assembly, testing, marking and packaging (ATMP) facilities
• Outsourced semiconductor assembly and testing (OSAT) operations

Focus on Serious Investors

Vaishnaw said the government will consider only fully complete applications under ISM 2.0, ensuring participation from serious investors and industry players.

Strengthening India's Electronics Supply Chain

The latest approvals and the launch of ISM 2.0 are part of India's broader strategy to build a stronger domestic electronics and semiconductor ecosystem, reduce import dependence, and support long-term growth in electronics manufacturing.

India’s Financial Sector Faces a New Cyber Threat: I4C Warns of AI-Powered Attacks on Banks and Fintechs

India’s cybercrime and cybersecurity authorities have issued one of their strongest warnings yet to the banking and financial services sector, cautioning that cybercriminals are increasingly using artificial intelligence to automate attacks, compromise systems at machine speed, and execute unauthorised fund transfers worth crores of rupees.

The alert, issued jointly by the Indian Cyber Crime Coordination Centre (I4C) and CERT-In, comes amid a series of cyber incidents affecting banks, non-banking financial companies (NBFCs), fintech firms, payment aggregators and digital lending platforms. Authorities say the attacks are financially motivated and are being powered by AI agents capable of identifying vulnerabilities, launching attacks and exploiting payment systems far faster than traditional cybercriminal operations.

AI Is Changing the Economics of Cybercrime

According to the advisory, cybercriminals are leveraging AI agents and "agentic AI" frameworks to automate attack chains that previously required significant human effort. These systems can rapidly identify weaknesses, generate attack scripts, adapt to changing environments and execute fraudulent transactions at machine speed.

The National Cybercrime Threat Analysis Unit (NCTAU), operating under I4C, noted that several cases have already involved multi-crore unauthorised transactions through automated fund disbursement systems and payment APIs.

Unlike conventional cyberattacks, AI-enabled attacks can significantly reduce the time between system compromise and financial theft, limiting the window available for institutions to detect and stop fraudulent activity.

How the Attacks Work

The advisory outlines a pattern that has emerged across multiple incidents.

Attackers first gain entry by exploiting unpatched software, misconfigured internet-facing servers, vulnerable IT infrastructure, or even customer-facing complaint and support systems. Once inside, they target automated payment infrastructure, particularly application programming interfaces (APIs) used for fund transfers, loan disbursements and settlement functions.

Authorities say the attack chain generally follows four stages:

• Compromise vulnerable systems through software flaws or configuration weaknesses.
• Gain access to payment and fund disbursement APIs.
• Transfer money into criminal "mule" accounts across multiple banks.
• Delete logs and evidence to hinder investigation and recovery efforts.

The stolen funds are often moved rapidly through IMPS and NEFT channels, making recovery increasingly difficult.

The Emergence of “Crafty Falcon”

CERT-In's Computer Security Incident Response Team for Finance (CSIRT-Fin) has assigned the designation CRAFTY FALCON to an AI-assisted threat actor believed to be responsible for the ongoing campaign. Authorities describe the actor as capable of surveying targets using machine intelligence and exploiting victims' own payment infrastructure against them.

CERT-In's investigation found evidence that the campaign is active and escalating, with continued reports of successful attacks even against organisations that had previously received warnings and undertaken remediation efforts. Some victims were reportedly re-targeted after incomplete remediation measures, while attacks were often timed to coincide with weekends, holidays and other periods of lower monitoring activity.

AI Tools Being Used by Attackers

CERT-In's analysis found that threat actors are using publicly available AI-based offensive security tools to accelerate attacks. The advisory specifically identified:

• ARTEX family of large language model-based offensive tools
• PentAGI autonomous multi-agent penetration testing system
• Cairn attack search engine
• CyberStrikeAI framework

According to CERT-In, these tools can autonomously execute attack chains, generate customised attack scripts and adapt exploit techniques based on target responses.

Investigators also discovered that attackers have:

• Targeted cloud infrastructure and serverless services.
• Exploited shared credentials and access tokens.
• Reverse-engineered application code to build customised exploits.
• Conducted small-value test transactions before launching larger thefts.
• Bypassed IP allow-listing protections using third-party infrastructure.

Why APIs Have Become the Primary Battleground

A recurring theme in recent regulatory and cybersecurity warnings is the vulnerability of APIs that connect banks with fintech companies and NBFCs.

The Reserve Bank of India (RBI) has recently intensified scrutiny of API security, asking banks to demonstrate compliance with cybersecurity requirements and assess weaknesses in their API ecosystems.

Reuters reported that the RBI has expressed concern over AI-driven attacks on financial infrastructure and sought details about institutions' preparedness for AI-related risks.

Regulators are particularly concerned because APIs serve as critical communication links between banks, fintech platforms and lending institutions. Any weakness in these connections could potentially enable attackers to manipulate payment instructions or move funds fraudulently.

Recent Incidents Raise Alarm

The warnings come amid several high-profile incidents across India's financial ecosystem.

Reuters reported that data belonging to approximately 3,900 customers was leaked from State Bank of India (SBI), the country's largest lender.

Separately, two Mumbai-based NBFCs reportedly suffered over 700 unauthorised transfers worth roughly $2 million after attackers allegedly compromised an API link used for loan disbursal instructions.

These incidents have reinforced concerns that attackers increasingly view smaller lenders, fintech firms and third-party vendors as softer entry points into the financial ecosystem.

What Financial Institutions Have Been Told to Do

The advisory directs banks, NBFCs, fintechs, payment aggregators and payment gateways to urgently implement protections outlined in CERT-In's critical advisories issued in October 2026.

Authorities also recommended several additional safeguards:

• Maintain a complete inventory of payment-related APIs.
• Disable obsolete, unused and test interfaces.
• Introduce daily and per-transaction limits.
• Verify beneficiary names before transfers.
• Monitor unusual transaction velocity and volumes.
• Improve coordination between security operations, transaction monitoring teams and IT departments.
• Implement continuous monitoring and heightened vigilance.

Financial institutions have additionally been instructed to:

• Report cyber incidents to CERT-In within six hours of detection.
• Report incidents to the RBI through the DAKSH portal.
• Coordinate with I4C for rapid freezing of fraudulent transactions where required.

A Wider Regulatory Push on AI Risk

The warning forms part of a broader regulatory effort to address AI-related risks in the financial system.

Earlier this year, the RBI proposed new guidelines requiring banks to establish board-approved risk management frameworks covering AI and machine learning models, including independent validation requirements and stronger governance controls. For generative AI systems that interact with customers, the RBI proposed additional cybersecurity safeguards and human oversight mechanisms.

At the same time, regulators in the United States, United Kingdom and other jurisdictions are stepping up efforts to manage AI-related risks as AI capabilities become increasingly integrated into both financial services and cybercrime operations.

The Bigger Picture

The I4C and CERT-In advisories signal a significant shift in India's cybersecurity landscape. Financial institutions have long faced cyber threats, but the emergence of AI-assisted attack frameworks is changing both the scale and speed of attacks.

Rather than simply helping hackers write malicious code, AI is increasingly being used to automate reconnaissance, adapt attacks in real time, exploit APIs, evade detection and accelerate money movement through financial systems. Authorities now view these capabilities as an immediate operational risk rather than a future concern.

For India's banks, fintechs and NBFCs, the message from regulators is clear: AI-powered cyberattacks are no longer theoretical. They are active, financially motivated and already being used in attempts to compromise financial infrastructure and move funds at machine speed.

Base Launches Upgrade to Make Transactions Faster and More Reliable

Introducing Base Denim

Base’s fourth upgrade, Denim, is now live on mainnet. Denim brings native 200ms blocks to Base that replaces flashblocks: five complete canonical blocks every second. Contracts can now read time to the millisecond onchain, and B20 gets safer transfers and simpler compliance controls.

Base’s north star is to bring the world onchain, starting with trading, financing, and payments. Those use cases need a chain that updates state often and lets builders reason about time precisely. Denim changes the block cadence of Base itself: instead of one block every two seconds with a pending-state preview in between, Base now produces a full canonical block every 200 milliseconds.

What’s in Denim?

Denim delivers three changes:

• Native 200ms blocks: five complete canonical blocks per second, replacing Flashblocks
• BaseTime: millisecond-resolution time for contracts and RPC clients
• B20 improvements: safer transfers and reusable compliance policies

Native 200ms blocks

Before Denim, Base produced one canonical block every two seconds. Flashblocks filled the gap by streaming incremental pending-state updates for the block being built, so apps could show a preview of state before the block landed.

Base now produces five canonical blocks per second, and each one is a real block, not a preview. Once your transaction is in a 200ms block, it is in. There are no preconfirmations that can be walked back, there is no pending state to reconcile, and there is no separate stream to subscribe to. Block production is simpler, more consistent, and more reliable.

Blocks cannot skip slots. Each block’s full timestamp is exactly 200ms after its parent’s, and the protocol validates that progression, so the cadence is a property of the chain rather than of the sequencer’s wall clock.

Why native blocks beat Flashblocks

No preconfirmation reorgs. A Flashblock was a preview of a block still being built, and a preview can be dropped from the block that finally lands. Apps that showed Flashblock state had to be ready to walk it back. A 200ms block is not a preview of anything: it is the canonical block, with the same guarantees as every other block on Base. Reorgs caused by Flashblocks are gone, along with the separate Flashblocks stream that could degrade while block production continues.

Every standard RPC just works. Sub-second state no longer lives behind a special subscription or a "pending" tag with Flashblocks-aware semantics. eth_subscribe("newHeads"), eth_getLogs, eth_call, eth_getTransactionReceipt and every other standard JSON-RPC method return 200ms state out of the box, so viem, ethers, Foundry and existing indexers work without a Flashblocks client or a reconciliation layer.

Faster canonical inclusion. Before Denim, a transaction waited up to two seconds for the next canonical block. Now the next canonical block is never more than 200ms away. Payments confirm in the block, trades settle in the block, and the app reads the receipt from the block, with no preconfirmed state to reconcile later.

Finer-grained time for DeFi. Five blocks per second give lending, trading and rewards protocols five opportunities per second to react: liquidations can execute in the first block after a price update rather than the next two-second block, and oracles and keepers can act on a 200ms cadence. With BaseTime, contracts also get the millisecond clock to match, so interest accrual, reward streaming and yield calculations can run at 200ms resolution instead of once per second.

Flashblocks is retired

Denim replaces Flashblocks. Base no longer produces Flashblocks streams, and the "pending" block tag no longer returns a preconfirmed state. Applications that consumed Flashblocks need to move to canonical block and RPC streams:

Before Denim	After Denim
eth_subscribe("newFlashblocks")	eth_subscribe("newHeads")
eth_subscribe("pendingLogs")	eth_subscribe("logs")
eth_subscribe("newFlashblockTransactions")	eth_subscribe("newHeads"), then fetch each block's transactions
eth_getBalance, eth_call, eth_getBlockByNumber with "pending"	The same methods against the latest canonical block

The full mapping is in Migrate From Flashblocks.

block.number advances ten times faster

Because Base now produces ten times as many blocks per second, any contract or offchain system that treats a block count as a duration will see that duration shrink to one tenth of its intended length. block.timestamp is unaffected and still advances in whole seconds.

Review any logic of this shape:

• Timelocks, cooldowns and exit delays written as block.number - start >= N
• Vesting, emission and difficulty schedules measured in blocks
• Per-block rate limits or caps that reset when block.number changes
• Deadlines set as expirationBlock = block.number + N
• Governance voting delay and period in blocks, including ERC20Votes with the default block-number clock()
• Fixed-cardinality TWAP oracles, which now cover roughly half as much wall-clock history before observe() reverts

Where you can redeploy or upgrade, replace block-count durations with block.timestamp comparisons. Where a block count is governance-tunable, divide it by ten. The 200ms Native Blocks spec has the full table.

BaseTime

With BaseTime, your app can measure elapsed time and check deadlines with millisecond precision, whether you’re running an auction, expiring an order or calculating rewards.

Ethereum block headers store timestamps in whole seconds, and Denim keeps that unchanged: block.timestamp in the EVM and the timestamp field in JSON-RPC responses are still seconds. With five blocks per second, five consecutive blocks share the same block.timestamp. A contract that accrues interest, streams rewards or expires orders by comparing timestamps sees zero elapsed time between four of every five blocks, then a full second jump.

BaseTime supplies the missing milliseconds, so time onchain moves with every block instead of stepping once per second.

Every Denim block carries a BaseTime metadata update at transaction index 1, right after the L1 info deposit, that writes the block’s sub-second part (0, 200, 400, 600 or 800) to the BaseTime predeploy at 0x4200000000000000000000000000000000000030. Because the deposit executes before user transactions, any contract in the block can read the block’s full millisecond timestamp.

Code Example

Use case: a contract that needs sub-second time, such as an auction or order-expiry check:

interface IBaseTime {
    function timestampMillisPart() external view returns (uint16); // 0, 200, 400, 600 or 800
    function timestampMs() external view returns (uint64);         // full Unix time in milliseconds
}

IBaseTime constant BASE_TIME =
    IBaseTime(0x4200000000000000000000000000000000000030);

function isExpired(uint64 expiresAtMs) internal view returns (bool) {
    return BASE_TIME.timestampMs() >= expiresAtMs;
}

Millisecond timestamps over RPC

Tooling gets the same precision without calling the predeploy. Block and header responses (eth_getBlockByHash, eth_getBlockByNumber, eth_getHeaderByHash, eth_getHeaderByNumber, eth_subscribe("newHeads")) add an optional timestampMs field, and mined transactions, logs and receipt logs add an optional blockTimestampMs.

For example, a block at 42.200 seconds returns:

{
  "timestamp": "0x2a",
  "timestampMs": "0xa4d8"
}

These values come from the authenticated BaseTime metadata in each block, not from an estimate based on the seconds field. The existing timestamp field is unchanged, so clients that ignore the new fields keep working. Pre-Denim blocks omit the new fields.

B20 improvements

Denim makes B20 tokens safer for users and gives issuers stronger and simpler compliance controls. These changes help prevent accidental sends to the token’s own address, enforce issuer transfer rules consistently, and reuse compliance lists. Existing integrations keep working unless noted below.

PolicyRegistry gains one view, invertedPolicyId. The token interface gains no new functions, events or errors.

Reusable compliance lists

Cobalt lets issuers combine policies with AND and OR operators. Denim adds NOT. Any policy ID can be inverted by setting a reserved bit, and isAuthorized returns the opposite of the base policy’s result. Members live on the base policy and are shared, not copied, so an issuer can use one address list to mean “only these addresses” in one scope and “exclude these addresses” in another, with no second list to keep in sync.

Example breakdown

• A compliance provider maintains one sanctioned allowlist whose members are sanctioned addresses.
• The issuer builds a composite transfer policy, KYC AND NOT sanctioned, passing invertedPolicyId(sanctioned) as the second child.
• A transfer to Alex, who is KYC-verified and not on the sanctions list, settles. If the provider adds Alex to the sanctions list, the next transfer to him fails. Nothing else changes, because the inverse reads the same list.

Stronger transfer controls for regulated assets

Issuers of restricted securities often require every transfer to be initiated by an approved party, such as a transfer agent. B20’s TRANSFER_EXECUTOR_POLICY is the allowlist for that pattern, but before Denim it only applied to transferFrom calls made by someone other than the holder. A holder could bypass it by calling transfer directly.

After Denim, TRANSFER_EXECUTOR_POLICY is checked on msg.sender for every transfer path, matching how the sender and receiver policies already work. B20 tokens launched with TRANSFER_EXECUTOR_POLICY set will automatically inherit the new behaviour noted above. Tokens that never set an executor policy keep the always-allow default and see no change.

Example breakdown

• A fund’s token sets TRANSFER_EXECUTOR_POLICY to an allowlist containing only its transfer agent.
• The agent calls transferFrom(alice, bob, 500) after Alice has approved it. The transfer succeeds.
• Alice calls transfer(bob, 500) directly. Before Denim this succeeded; after Denim it reverts with PolicyForbids, because Alice is not an allowlisted initiator.

Note: The issuer chooses whether to set an executor policy and who is on it; Base does not decide who may initiate transfers.

Protection against lost funds

Users sometimes paste the token’s own address as the recipient. A B20 token is a precompile with no holder key, so tokens credited to it were stuck unless the issuer seized them back.

After Denim, any transfer, mint or seizure whose recipient is the token’s own address reverts with the existing InvalidReceiver error, the same error wallets already handle for address(0).

Example breakdown

• Alex copies the wrong address from an explorer and tries to send 500 tokens to the token contract itself.
• The transfer reverts with InvalidReceiver. Alex’s balance is unchanged, and the wallet shows the same error it shows for a send to the zero address.
• Self-sends, sends to other B20 tokens, approvals and burns are unaffected. An issuer can still recover a balance that reached the token address before Denim with seizeWithMemo(address(token), treasury, amount, memo) if they have opted into seize functionality for their token.

For technical details and migration steps, see the Denim B20 changelog:

• Token Receiver
• Transfer Executor Enforcement
• NOT / Invert Policies

How Denim impacts you

Users

No action needed. Transactions land in canonical blocks that arrive every 200ms, and mistaken sends to a B20 token’s own address now fail instead of locking funds.

App and wallet developers

If you consume Flashblocks or use the "pending" block tag, migrate to canonical block subscriptions and the latest block: see Migrate From Flashblocks.

If you need sub-second time, read timestampMs from block responses or call the BaseTime predeploy.

Contract developers

Audit any logic that converts block counts to time. block.number now advances ten times faster in wall-clock time; block.timestamp is unchanged.

See Block-Number-Based Contract Logic.

Trading teams and market infrastructure

You now observe a canonical state every 200ms, the next block is never more than 200ms away, and blocks, transactions and logs carry millisecond timestamps.

There is no pending-state stream to reconcile against canonical blocks and no preconfirmation that can be dropped from the final block.

DeFi protocols

Lending, DEX and rewards protocols get five blocks per second to liquidate, rebalance and update, and can read BaseTime.timestampMs() to accrue interest, stream rewards and expire orders at 200ms resolution instead of once per 2 seconds.

Review block-count timing assumptions before relying on the new cadence.

RPC providers, indexers and explorers

Expect ten times the block count per unit time, and the new optional timestampMs and blockTimestampMs fields on block, transaction, log and receipt responses.

Flashblocks streams have stopped.

Bridges and proof flows that read historical block hashes or beacon roots retain the same number of values, but that history now covers one tenth of the elapsed time.

Issuers

If your token sets a restrictive TRANSFER_EXECUTOR_POLICY, add holders (or a policy covering them) to the executor allowlist if you want holder-initiated transfers to keep working.

Treat the token’s own address as an invalid recipient in your tooling.

Use invertedPolicyId to replace mirrored allow and block lists.

If there's something we can do better, we want to hear it. Reach us on X, Discord, or GitHub.

Disclaimer

Base is open-source, permissionless blockchain infrastructure. Base provides neutral protocol infrastructure only and does not control the persons, applications, or assets that use it.

B20 tokens are deployed, configured, and administered solely by their respective issuers; issuer-controlled features such as minting, burning, freezing, and seizure are exercised at the issuer's sole discretion.

References to third-party issuers or assets are informational and not an endorsement.

Except with respect to assets that Coinbase or its affiliates expressly issue (which are offered only in eligible jurisdictions and governed by their own terms and disclosures), Coinbase, including Base, is not the issuer, investment adviser, broker, dealer, underwriter, promoter, distributor, or transfer agent for any B20 token or transaction, and nothing here is investment advice or a recommendation to buy or sell any digital asset.

Forward-looking statements about future upgrades, features, or performance are subject to change and are not commitments to deliver.

Illustrative examples are hypothetical and are provided solely to demonstrate potential use cases for new functionality.

They are not exhaustive and do not constitute a recommendation, solicitation, or representation that any particular use case, strategy, application, asset or outcome will be available, suitable, profitable or successful.

LTM, ServiceNow Team Up to Bring Agentic AI Into the Enterprise Mainstream

• Combines the ServiceNow AI Platform with LTM’s domain and technology expertise to help enterprises deploy governed agentic AI at scale.
• Strengthens joint go-to-market efforts for more than 700 shared customers, using LTM’s own transformation as a proven enterprise blueprint.

ServiceNow (NYSE: NOW), the Super Intelligence Control Tower for business reinvention, and LTM, the Business Creativity partner to the world's largest enterprises, today announced a planned expansion of their partnership to scale agentic AI and accelerate joint go-to-market initiatives for customers. The companies will bring together the ServiceNow AI Platform and LTM’s domain, engineering, and transformation expertise to help enterprises move agentic AI programs from isolated use cases to governed, enterprise-wide adoption and measurable business outcomes.

As an Elite ServiceNow Partner serving more than 700 joint customers, LTM will use its own enterprise transformation as a ‘client-zero’ blueprint. LTM has deployed 1,500 ServiceNow AI Agents across its operations, creating a digital workforce that works alongside employees, while ServiceNow Super Intelligence Control Tower provides a single system of action for AI inventory and risk oversight, with LTM expecting up to an 80% improvement in AI asset management and efficiency. LTM’s own ServiceNow deployment will inform joint solutions and go-to-market programs designed to help customers adopt, govern, and scale agentic AI with greater speed and confidence.

The ServiceNow AI Platform is already helping LTM achieve measurable value across cybersecurity, HR, IT, and project delivery. ServiceNow solutions are streamlining security operations, reducing IT ticket volumes, and enabling up to 87% faster senior management review cycles.

Our expanded partnership with ServiceNow will help enterprises move agentic AI from experimentation to meaningful business impact,” said Krishnan Iyer, Chief Growth Officer, LTM. By combining the ServiceNow Platform with LTM’s domain, engineering, and transformation expertise, we will jointly develop solutions and go-to-market programs that help customers deploy agentic AI with greater speed and confidence.

LTM is showing what an AI-powered enterprise looks like: a new workforce of AI agents working alongside their people, delivering faster threat responses, fewer IT tickets, and higher HR productivity. But every agent is a new identity with enterprise access, and most companies can't say where their agents are, what they're doing, or who's accountable, said Kulmeet Bawa, GVP & Managing Director, ServiceNow India & SAARC. With the ServiceNow Super Intelligence Control Tower, LTM has visibility and control, so their people stay focused on the judgment calls that matter. Now more than 700 joint customers get to learn from a partner who's already done it.

About ServiceNow

ServiceNow (NYSE: NOW) is the Super Intelligence Control Tower for business reinvention. The ServiceNow platform integrates with any model, any cloud, and any data source to orchestrate, govern, and secure work across the agentic enterprise. ServiceNow gives customers the enterprise context and control to build and scale confidently. With more than 100 billion workflows running on the platform each year, ServiceNow helps organizations turn fragmented operations into coordinated, autonomous work for IT, CRM, Security, Employee Experience, and more. Learn how ServiceNow puts AI to work for people at www.servicenow.com.