<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel rdf:about="https://hdl.handle.net/20.500.12761/2">
<title>IMDEA Networks</title>
<link>https://hdl.handle.net/20.500.12761/2</link>
<description/>
<items>
<rdf:Seq>
<rdf:li rdf:resource="https://hdl.handle.net/20.500.12761/2039"/>
<rdf:li rdf:resource="https://hdl.handle.net/20.500.12761/2038"/>
<rdf:li rdf:resource="https://hdl.handle.net/20.500.12761/2037"/>
<rdf:li rdf:resource="https://hdl.handle.net/20.500.12761/2036"/>
</rdf:Seq>
</items>
<dc:date>2026-05-24T23:52:17Z</dc:date>
</channel>
<item rdf:about="https://hdl.handle.net/20.500.12761/2039">
<title>Blind 5G NR LEO Initial Access Receiver</title>
<link>https://hdl.handle.net/20.500.12761/2039</link>
<description>Blind 5G NR LEO Initial Access Receiver
Jaminon-De Roeck, Chen; Timothy, Otim; Santaromita, Giuseppe; Giustiniano, Domenico
LEO satellite links pose severe challenges&#13;
for 5G Non-Terrestrial Network (NTN) initial access&#13;
due to large carrier frequency offsets, rapidly varying&#13;
Doppler, and low SNR, making fully blind operation&#13;
essential in cold-start scenarios. Using a real 5G NTN&#13;
LEO over-the-air testbed emulation, we show that&#13;
Doppler compensation accuracy directly governs user&#13;
equipment (UE) connection outcomes, with residual&#13;
errors below 3 kHz required for reliable synchronization&#13;
and attachment. We then present a fully blind, feedfor&#13;
ward receiver that computes bounded reliability scores&#13;
at each processing stage and uses them for hypothesis&#13;
gating, burst selection, conservative log-likelihood ratio&#13;
(LLR)-domain combining, weighting, and final lock de&#13;
cisions. The design includes a conservative, reliability&#13;
aware multi-Synchronization Signal Block (SSB) Phys&#13;
ical Broadcast Channel (PBCH) soft-combining stage&#13;
that only supplements single-SSB channel quality as&#13;
sessment. Deterministic results from 3GPP-compliant&#13;
simulations demonstrate robust blind synchronization&#13;
under ±100kHz frequency offsets and successful PBCH&#13;
decoding at low signal-to-noise ratios in urban line-of&#13;
sight (LOS) and non-line-of-sight (NLOS) conditions.&#13;
The simulation code used is publicly available.
</description>
<dc:date>2026-04-20T00:00:00Z</dc:date>
</item>
<item rdf:about="https://hdl.handle.net/20.500.12761/2038">
<title>Breaking Sandwich MEV in ERC-20 DeFi via Context-Aware Directional Constraints</title>
<link>https://hdl.handle.net/20.500.12761/2038</link>
<description>Breaking Sandwich MEV in ERC-20 DeFi via Context-Aware Directional Constraints
Arote, Prerna
Decentralized exchanges (DEXs) are a core component of decentralized finance (DeFi) but remain vulnerable to Maximal Extractable Value (MEV) attacks, particularly sandwich attacks that exploit transaction ordering across accounts and blocks. Existing defenses often rely on protocol modifications or identity-based assumptions, limiting their practicality and robustness.&#13;
&#13;
We present Context-Aware Directional Constraint (CADC), a lightweight application-layer defense implemented as an ERC-20–compatible token. CADC enforces directional consistency within pool-specific execution contexts and maintains a per-direction entry price to prevent both immediate and delayed profit extraction. By constraining the temporal and price conditions required for attack execution, CADC remains effective against multi-address and cross-block strategies. &#13;
Evaluation on a testnet shows that CADC prevents same-block and delayed sandwich attacks while preserving normal trading behavior, with minimal overhead (2--3k gas per pool interaction, 3--8% of typical swaps). CADC provides a practical and deployable MEV mitigation without requiring changes to the underlying blockchain protocol.
</description>
<dc:date>2026-06-01T00:00:00Z</dc:date>
</item>
<item rdf:about="https://hdl.handle.net/20.500.12761/2037">
<title>Mind the Gap: Liquidity Poisoning Attacks on Multihop Cross-Chain Arbitrage</title>
<link>https://hdl.handle.net/20.500.12761/2037</link>
<description>Mind the Gap: Liquidity Poisoning Attacks on Multihop Cross-Chain Arbitrage
Arote, Prerna
Cross-chain bridges enhance DeFi liquidity but introduce temporal gaps that expose multihop sequence-dependent arbitrage (SDA) to adversarial manipulation. Prior work attributes the rarity of SDA primarily to latency and transaction costs. We hypothesize that adversarial fragility is an additional factor and demonstrate this in 10 real multihop SDA paths from Allium data: bridge delays create predictable windows in which intermediate liquidity can be manipulated.&#13;
&#13;
We introduce Multihop SDA Liquidity Poisoning (MSLP), an attack model that exploits cross-chain asynchrony to degrade arbitrage profits without requiring transaction reordering or violating execution constraints. In our dataset, MSLP requires median capital of USD 21 to render 90% of paths unprofitable, reducing mean profit from USD 28.42 to USD -3.29. These results suggest that, beyond execution efficiency, the robustness of intermediate market states plays a critical role in the viability of cross-chain arbitrage.
</description>
<dc:date>2026-06-01T00:00:00Z</dc:date>
</item>
<item rdf:about="https://hdl.handle.net/20.500.12761/2036">
<title>Boosting Concurrency and Fault-Tolerance for Reconfigurable Shared Large Objects</title>
<link>https://hdl.handle.net/20.500.12761/2036</link>
<description>Boosting Concurrency and Fault-Tolerance for Reconfigurable Shared Large Objects
Trigeorgi, Andria; Nicolaou, Nicolas; Georgiou, Chryssis; Fernández Anta, Antonio; Hadjistasi, Theophanis; Stavrakis, Efstathios
Nowadays the traditional file systems cannot handle the new requirements in terms of volume of data, high&#13;
performance, fault-tolerance, and improved capabilities. So Distributed Storage Systems (DSS) took place to&#13;
cover the need of a shared storage between separate systems, provide a scalable storage to serve thousands&#13;
of servers, and improve the fault-tolerance. To this respect, a series of issues need to be properly addressed:&#13;
scalability, the ability to handle large data, high performance even under heavy access concurrency, versioning,&#13;
and fault-tolerance.&#13;
In this work, we propose CoBFS, a framework of a DSS designed to boost the concurrent access to large&#13;
shared data objects (such as files), while maintaining strong consistency guarantees. CoBFS has two key&#13;
design factors: data striping and versioning-based concurrency control (through coverability) to enable higher&#13;
operation performance on large concurrent data objects. To this respect, we introduce the notions of a block as&#13;
a “bounded” Read/Write register, of a fragmented object as a sequence of blocks, and of fragmented coverable&#13;
linearizability, a strong consistency property suitable for fragmented objects.&#13;
CoBFS adopts a modular architecture, separating the object fragmentation process from the shared memory&#13;
service allowing to use different shared memory implementations. At first, we use as storage a static atomic&#13;
distributed shared memory (ADSM) emulation, the well known ABD, yielding CoABDF, which satisfies&#13;
fragmented coverable linearizability. Then, we substitute the storage layer of CoBFS with a dynamic (reconfigurable)&#13;
storage algorithm, called Ares, yielding CoAresF; CoAresF allows the addition and removal of&#13;
servers without system interruptions and improves the storage efficiency due to the use of an erasure-coded&#13;
mechanism. We conduct an extensive experimental evaluation on the Emulab and AWS EC2 testbeds, illustrating&#13;
the benefits of our approaches, as well as other interesting tradeoffs. We believe that CoBFS’s features&#13;
(versioning, high concurrent accesses, handling large objects) has the potential of benefiting any static or&#13;
dynamic storage algorithm to further extend its functionality for data-intensive applications at large scale.
</description>
<dc:date>2026-03-01T00:00:00Z</dc:date>
</item>
</rdf:RDF>
