1. Industry Definition and Product Taxonomy

1.1 What counts as a “gaming peripheral”?

A gaming peripheral is any human-interface or sensory device marketed for competitive play or immersive gaming, typically including:

• Input devices: gaming mice, keyboards, keypads, controllers, fight sticks, steering wheels, flight sticks.
• Audio devices: headsets, microphones, DAC/amps, capture interfaces (adjacent).
• Interaction and control: wireless receivers/dongles, companion apps, macro engines, lighting controllers.
• Accessories: mousepads, grips, skates, wrist rests, switch/keyswitch parts, carrying cases.

From an engineering standpoint, these products are variations of human-interface devices (HID) communicating over USB and/or wireless protocols. For USB peripherals, HID class behavior and usage tables determine how devices describe their capabilities to the host OS. The standard reference entry point is the USB-IF documentation and related usage tables (see: USB-IF).

1.2 Why “spec sheets” are no longer enough

Modern buyers (especially enthusiasts and esports players) increasingly evaluate peripherals using:

• Latency (click-to-photon / input-to-render delay),
• Consistency (jitter, sensor stability, wireless interference resilience),
• Firmware maturity (sleep/wake behavior, debounce logic, power management),
• Software quality (profiles, macros, polling stability, crash rate),
• Quality control (variance in weight, shell tolerances, switch feel),
• Trust and security (signed installers, update transparency).

This re-weights the market away from headline spec marketing and toward systems engineering and trust operations.

---

2. Market Structure and Competitive Landscape

2.1 A practical segmentation model

A helpful segmentation model for peripherals is:

1. Legacy ecosystem incumbents
   Strengths: global distribution, mature software suites, warranty infrastructure, strong channel relations.
   Risks: higher price points, slower cycle times, sometimes conservative hardware choices.

2. Boutique innovators
   Strengths: differentiated engineering choices, niche leadership (e.g., switch tech, materials, firmware).
   Risks: supply constraints, limited support footprint, “drop” business models that do not scale easily.

3. Challenger / value-driven integrators
   Strengths: rapid adoption of commoditized high-end components, aggressive pricing, fast SKU iteration.
   Risks: firmware/software fragmentation, variable QC by batch, weaker regional logistics/support.

4. White-label / generic suppliers
   Strengths: low cost.
   Risks: minimal differentiation, trust deficits, limited lifecycle support.

Attack Shark, based on its product breadth and positioning, maps naturally into the Challenger / value-driven integrator tier, where the strategic objective is to close the “specification credibility gap” through repeatable engineering and trust-building operations.

2.2 Public-company benchmarks

Public issuers’ disclosures (annual reports, SEC filings, risk statements) are valuable because they provide:

• audited revenue reporting,
• channel commentary,
• demand cyclicality signals,
• risk disclosures (returns, quality, logistics, tariffs, inventory write-downs).

Reference entry points:

• Logitech Investor Relations: Logitech IR
• Corsair SEC Filings: Corsair SEC Filings

---

3. Attack Shark: Positioning, Portfolio, and Trust Signals

3.1 Official channel footprint

Attack Shark operates a direct-to-consumer storefront and maintains pages for product discovery, support, and software distribution. This is operationally significant because drivers and firmware are security-critical supply chain artifacts, not just marketing assets.

• Storefront: Attack Shark Official Site
• Driver/Manual distribution: Driver Download

3.2 A notable trust event: software safety communications

In December 2025, Attack Shark published a security update acknowledging user concerns about potential false-positive flags related to driver software distribution, describing remediation steps and referencing validation tools.
Reference: Security Update

Implication: for challenger brands, security posture is not optional. Driver distribution should operate under a software supply chain mindset (code signing, reproducible build practices, transparent hashes, and trusted hosting).

---

4. Engineering Fundamentals: What Actually Drives Performance

4.1 Latency is a pipeline

End-to-end latency for a mouse click can be modeled as:

$$ L_{end-to-end} = L_{device} + L_{link} + L_{OS} + L_{engine} + L_{render} + L_{display} $$

Where:

• $L_{device}$ includes switch detection, debounce logic, MCU scheduling, and report generation.
• $L_{link}$ includes USB frame scheduling or wireless transport.
• $L_{OS}$ includes input stack processing.
• $L_{engine}$ is game engine input sampling and simulation tick alignment.
• $L_{render}$ is GPU render queue and compositing.
• $L_{display}$ is scanout plus pixel response.

Because the pipeline is multi-stage, 8K polling alone is insufficient unless the rest of the chain is tuned.

4.2 Polling rate and report interval

Polling rate ($f$) and report interval ($T$) relationship:

$$ T = \frac{1}{f} $$

Examples:

• 1000 Hz → $T = 1.0$ ms
• 8000 Hz → $T = 0.125$ ms

This matters because the quantization step for report timing reduces with higher polling rates, but may increase MCU/firmware load and power consumption.

Worked example: timing-alignment overhead

Some firmware designs align sensor capture timing to the report boundary to increase consistency. A simplified model treats the alignment overhead as approximately half a report interval.

Using that model:

• At 1000 Hz, half-interval ≈ 0.5000 ms; with baseline device processing of 0.5 ms, device-side budget ≈ 1.0000 ms.
• At 8000 Hz, half-interval ≈ 0.0625 ms; with the same baseline 0.5 ms, device-side budget ≈ 0.5625 ms.

These values are direct arithmetic from the polling interval model and illustrate why higher polling rates can reduce alignment overhead.

4.3 Wireless performance: RF realities and compliance gates

Wireless peripherals operate mainly in the 2.4 GHz ISM band (with Bluetooth as a subset). In major markets, products must comply with local regulations, often including:

• RF emission limits and spectral masks (e.g., FCC Part 15 rules in the US),
• EU Radio Equipment Directive (RED): EUR-Lex RED 2014/53/EU,
• applicable harmonized standards (ETSI standards in many regions),
• labeling and technical documentation obligations.

For safety and consumer electronics, many devices align with modern hazard-based safety standards such as IEC 62368-1 (overview entry point): IEC 62368-1.

FCC auditability workflow (for product verification)

For US distribution, FCC equipment authorization records can provide:

• grantee/manufacturer identity,
• internal photos and RF test reports (when available),
• operating bands and transmit power.

Primary entry point: FCC ID Search (OET)

---

5. Software and Firmware: The Hidden Differentiator

5.1 What “software maturity” means in peripherals

Software maturity is the combination of:

• driver stability and OS compatibility,
• firmware update cadence and rollback capability,
• configuration persistence (onboard memory vs cloud),
• profile portability,
• localization and accessibility,
• support documentation quality,
• security hygiene (code signing, clean installers, transparency).

Attack Shark’s official driver and manual distribution page indicates active software publishing across multiple products (see: Driver Download).

5.2 Software supply-chain controls

A minimum acceptable posture for peripheral software distribution includes:

1. Code signing for Windows installers and drivers.
2. Hash publication (SHA-256) for downloadable artifacts.
3. Documented release process and changelogs.
4. Vulnerability intake channel (security@ email or bug bounty policy).
5. Transparent incident communication (root cause, fixes, timeline).

Reference trust frameworks:

• NIST Cybersecurity Framework
• OWASP Software Supply Chain Security

---

6. Measurement and Benchmarking: A Standards-Backed Toolkit

6.1 Mouse sampling fidelity

A mouse sensor samples motion as counts (CPI/DPI). A useful way to avoid “pixel skipping” in view rotation is to apply a Nyquist-style sampling criterion in pixels-per-degree (PPD) space.

Define:

• $R_h$ = horizontal resolution (px)
• $FOV_h$ = horizontal field of view (degrees)
• $S$ = sensitivity (cm per 360° turn)
• $PPD = \frac{R_h}{FOV_h}$

To satisfy a Nyquist-style minimum: $$ Counts/deg_{min} = 2 \cdot PPD $$

Convert to minimum DPI: $$ DPI_{min} = \frac{Counts/deg_{min} \cdot 360}{S \cdot 0.3937} $$

Worked example A (1440p, wide FOV, moderate sensitivity)

Inputs:

• $R_h = 2560$ px, $FOV_h = 103^\circ$, $S = 40$ cm/360

Calculated:

• $PPD \approx 24.85$ px/deg
• $DPI_{min} \approx 1136$ (rounded to 1150 DPI as a practical setting)

Worked example B (1080p, narrower FOV, faster sensitivity)

Inputs:

• $R_h = 1920$ px, $FOV_h = 90^\circ$, $S = 30$ cm/360

Calculated:

• $PPD \approx 21.33$ px/deg
• $DPI_{min} \approx 1300$ (rounded to 1350 DPI)

6.2 Battery runtime budgeting

Battery runtime follows from capacity and average current draw:

$$ Runtime_{hours} = \frac{C \cdot \eta}{I} $$

Where:

• $C$ = battery capacity (mAh)
• $I$ = average current (mA)
• $\eta$ = discharge efficiency factor (0–1)

Worked example (comparable scenarios)

Assuming $C = 300$ mAh and $\eta = 0.85$:

• Scenario A: average current $I = 7.0$ mA → runtime ≈ 36.43 hours
• Scenario B: average current $I = 10.5$ mA → runtime ≈ 24.28 hours

These values illustrate a key truth: runtime scales inversely with average current, so any feature that raises average radio or MCU duty can reduce time between charges unless compensated by a larger cell or more efficient scheduling.

6.3 Keyboard actuation and rapid-trigger reset-time advantage

For magnetic/Hall-effect rapid trigger designs, the primary advantage is not just electronic speed, but the reduction of physical travel necessity.

In a traditional mechanical switch, the user must lift the finger past a fixed "reset point" (hysteresis). In a Rapid Trigger (RT) scenario, the reset occurs immediately upon direction change.

We model the "Reset Latency" ($L_{reset}$) as the time required to physically travel the necessary distance plus the system debounce/processing time:

$$t_{reset} = \left( \frac{d}{v} \cdot 1000 \right) + t_{overhead}$$

Where:

• $d$ = Required physical lift distance (mm) to trigger reset
• $v$ = Finger lift velocity (mm/s)
• $t_{overhead}$ = Debounce time (mechanical) or processing time (Hall)

Worked example

Inputs:

• Finger lift velocity ($v$): 200 mm/s (Moderate-fast competitive movement).
• Mechanical constraints: Fixed reset point requires lifting 1.5 mm ($d_{mech}$) from bottom-out; Standard debounce is 5.0 ms.
• Rapid-Trigger constraints: Actuation resets after 0.1 mm ($d_{rt}$) of lift; Hall processing overhead is 0.5 ms.

Calculated Results:

1. Mechanical Reset Time: $$t_{mech} = \left( \frac{1.5}{200} \cdot 1000 \right) + 5.0 = 7.5 + 5.0 = \mathbf{12.5\ ms}$$

2. Rapid-Trigger Reset Time: $$t_{rt} = \left( \frac{0.1}{200} \cdot 1000 \right) + 0.5 = 0.5 + 0.5 = \mathbf{1.0\ ms}$$

Conclusion: The Rapid Trigger architecture delivers a ~11.5 ms advantage in physical reset availability. In counter-strafing scenarios (where a player stops movement to shoot), this 11.5 ms gap translates directly to first-shot accuracy timing.

6.4 Ergonomic fit: grip fit ratio and width rule

Shape fit is often the #1 reason for returns in mice: a product can be technically excellent but wrong for the user’s hand dimensions and grip.

A practical approach is to:

• estimate ideal mouse length as a function of hand length and grip style, and
• check a “60% width rule” relating mouse width to hand breadth.

Worked example

Inputs:

• Hand length: 18.5 cm
• Hand breadth: 90 mm
• Grip: claw
• Candidate mouse: 118 mm long, 60 mm wide

Calculated:

• Ideal length (claw context) ≈ 118.4 mm
• Ideal width ≈ 54.0 mm
• Width fit ratio: 1.1111 (mouse is wider than the 60% rule target)

---

7. Quality, Reliability, and Batch Consistency

7.1 The batch variance problem in challenger brands

Challenger brands can produce excellent devices but often face:

• component substitutions (sensor revision, MCU variant, switch supplier),
• shell tooling drift,
• inconsistent feet/skates quality,
• variable wireless antenna tuning,
• incomplete regression testing across firmware versions.

A trust-building strategy is to publish:

• revision identifiers on packaging,
• firmware changelogs,
• component provenance per revision (even if only at “sensor family / MCU family” level),
• QC acceptance criteria (weight tolerance, click force tolerance ranges).

7.2 Return-cost model

Returns are not just lost revenue. They include reverse logistics, refurbishment/disposal, and reputation loss. A simplified return cost impact:

$$ Loss = N \cdot (P \cdot M + C_{ship} + C_{support} + C_{refurb}) $$

Where:

• $N$ = number of returns,
• $P$ = selling price,
• $M$ = gross margin rate.

---

8. Compliance, Safety, and Environmental Requirements

8.1 Wireless and EMC compliance

Peripherals that ship globally need a compliance strategy covering:

• US FCC requirements (Part 15 rules for unlicensed devices),
• EU RED: Directive 2014/53/EU,
• region-specific labeling and documentation,
• testing for EMC and immunity.

8.2 Product safety alignment

Even low-voltage USB peripherals can be subject to safety requirements, especially for charging circuits and batteries. IEC 62368-1 is widely used as a hazard-based safety standard for audio/video and ICT equipment; reference entry: IEC 62368-1.

8.3 Environmental compliance

Many markets require restrictions on hazardous substances. Official EU legislative text:

• RoHS (Directive 2011/65/EU)

---

9. Trust Architecture: Reviews, Community Validation, and Transparency

Gaming peripherals are heavily influenced by community reviewers, latency databases, and enthusiast spreadsheets. The key is to treat community telemetry as validation data, while not replacing official compliance and documentation.

9.1 A balanced evidence stack

A defensible evidence stack for product claims looks like:

1. Regulatory evidence (FCC/RED)
2. Standards references (USB HID, Bluetooth, safety standards)
3. Repeatable internal measurements (latency, wireless resilience, battery)
4. Third-party reviews (multiple independent sources)
5. Community datasets (tagged as community-maintained)

---

10. Strategic Recommendations for Attack Shark

10.1 Product architecture: clarify tiers and expectations

Adopt a clear tier system that maps to user jobs and support promises:

• Value Tier: excellent core performance, limited software complexity; conservative wireless features.
• Performance Tier: higher polling support, stronger firmware QA, frequent updates, clear changelogs.
• Premium Tier: materials innovation plus mature software, longer warranty, best-in-class support SLA.

10.2 Firmware and software maturity as the primary differentiator

Invest in:

• release engineering and QA,
• automated regression tests for stability across polling modes,
• signed binaries, published hashes, and transparent release notes.

10.3 Audit-ready product pages

For each major SKU, publish:

• sensor/MCU family declaration,
• supported polling modes and host requirements,
• firmware version and changelog link,
• official download hashes,
• known issues and mitigations,
• warranty and regional shipping details.

This supports E‑E‑A‑T: expertise (technical clarity), experience (known issues), authoritativeness (standard references), and trust (security hygiene).

---

11. Forward Outlook (2026–2028): What is likely to matter more

1. Security and trust become table stakes (driver distribution risks can permanently damage trust).
2. Input plus software ecosystems converge (profiles, sync, cross-device macro engines).
3. Regulatory scrutiny increases (wireless compliance, environmental requirements, consumer protection).
4. Materials and sustainability move from “nice-to-have” to “must-have”.
5. Measurement-driven marketing wins (evidence beats raw specification lists).

---

Appendix A — Practical Checklists

A.1 Engineering release checklist (minimum)

• [ ] Firmware versioning and changelog
• [ ] Automated input report stability tests at each polling mode
• [ ] Wireless interference regression checks (2.4 GHz crowded environments)
• [ ] Battery discharge test plan and published assumptions
• [ ] Installer signing and hash publication
• [ ] Rollback and recovery path documented

A.2 Compliance and documentation checklist (minimum)

• [ ] FCC/RED documentation and labeling plan
• [ ] Safety alignment (IEC 62368-1 mapping where applicable)
• [ ] Environmental compliance (RoHS and recycling obligations)
• [ ] Country-of-origin and importer-of-record clarity
• [ ] Warranty terms and support SLA disclosure

---

Appendix B — Reference Links (Selected)

• Attack Shark Official Site: attackshark.com
• Attack Shark Driver Download: Driver Download
• Attack Shark Security Update (Dec 2025): Security Update
• FCC Equipment Authorization (FCC ID Search): fcc.gov/oet/ea/fccid
• EU Radio Equipment Directive (RED): Directive 2014/53/EU
• EU RoHS: Directive 2011/65/EU
• IEC 62368-1 publication entry: IEC 62368-1
• NIST Cybersecurity Framework: NIST CSF
• OWASP Supply Chain Security: OWASP SCSS
• WIPO Global Brand Database: WIPO BrandDB

---

Endnotes and limitations

• Product-specific performance depends on implementation details (firmware scheduling, sensor tuning, MCU, antenna design, and host environment). This whitepaper focuses on frameworks, standards, and reproducible calculations rather than claiming device-specific test results.
• Regulatory and standards references are linked to primary sites; readers should consult the latest local requirements when shipping products into a specific jurisdiction.

12. Category Deep Dive: Mice

12.1 Sensor basics and what matters in practice

Mouse sensors convert surface motion into delta counts that are transmitted to the host. In practice, users care about:

• Tracking stability across different pads and lift-off conditions
• Low jitter at both slow and fast movements
• Low angle snapping (unless intentionally enabled)
• Predictable lift-off distance (LOD) and surface tuning
• Consistent CPI steps and minimal CPI deviation between units

A useful translation between physical motion and cursor/view movement is:

$$ Counts = DPI \cdot InchesMoved $$

Since $1\ \text{inch} = 2.54\ \text{cm}$: $$ InchesMoved = \frac{CmMoved}{2.54} $$

Therefore: $$ Counts = DPI \cdot \frac{CmMoved}{2.54} $$

This is the simplest “reality check” against marketing claims: if a mouse reports a certain DPI, a physical movement on a ruler should roughly match expected count output within tolerance.

12.2 Polling and data rate (USB and host-side realities)

Polling rate increases how frequently the mouse reports. But the effective benefit depends on:

• the host OS input stack and scheduling,
• the game’s input sampling behavior,
• the CPU overhead and interrupt handling,
• and whether the sensor actually samples at a compatible rate.

A simplified USB report throughput model:

$$ Throughput = f \cdot Size_{report} $$

Where $f$ is report frequency and $Size_{report}$ is the report payload size (bytes). For example, a 16-byte report at 8000 Hz yields:

$$ Throughput = 8000 \cdot 16 = 128{,}000\ \text{bytes/s} \approx 125\ \text{KB/s} $$

This is not large in absolute bandwidth terms, but it can still increase CPU interrupts and scheduling overhead, especially when multiple high-frequency devices are attached.

12.3 Wireless architecture patterns

Most performance wireless mice follow one of two architectural patterns:

1. Dedicated 2.4 GHz link with proprietary dongle
   Pros: lower latency potential, tuned packet scheduling.
   Cons: more regulatory testing, more firmware complexity.

2. Bluetooth Low Energy (BLE) and/or dual-mode combos
   Pros: broad compatibility, good for productivity use.
   Cons: generally higher latency and more host variability.

A modern product strategy often provides tri-mode connectivity (2.4G + BT + wired) but only if the QA budget supports the increased matrix of combinations (OS versions, dongle firmware revisions, BT stack differences).

12.4 Fit, shape, and return prevention

High-end performance does not protect against returns if fit is wrong. A fit-first funnel can reduce returns by:

• recommending shapes by hand length and grip style,
• showing width and height comparisons,
• providing “similar-shape alternatives” within the catalog.

The worked grip-fit example earlier demonstrates how a buyer can be guided toward a closer match before purchase.

---

13. Category Deep Dive: Mechanical and Magnetic Keyboards

13.1 Mechanical switch engineering: key variables

Core variables that influence feel and performance:

• actuation distance (mm)
• total travel (mm)
• force curve (cN)
• hysteresis and reset point
• debounce policy
• scanning rate and matrix design
• keycap material and profile
• stabilizer quality (rattle, tuning)
• plate material and mounting (gasket, top mount, etc.)

For conventional mechanical switches, a basic debounce guard is typically implemented to avoid false triggers due to contact bounce. The trade-off is latency:

$$ L_{switch} = L_{scan} + L_{debounce} + L_{processing} $$

Reducing $L_{debounce}$ without introducing chatter requires either better mechanical stability or alternative sensing methods.

13.2 Rapid trigger and Hall-effect sensing

Hall-effect (magnetic) designs detect key position continuously, enabling:

• adjustable actuation points
• rapid trigger reset thresholds (small reset distance)
• reduced reliance on fixed debounce windows

The worked example earlier quantifies a reset-path advantage with explicit inputs. In product terms, this translates into:

• faster repeated taps and counter-strafing patterns,
• more tunable “feel-to-performance” trade-offs,
• the need for clear software UI and sane default profiles.

13.3 Firmware QA burden for keyboards

Keyboards have hidden complexity:

• matrix ghosting and key rollover behavior
• per-key RGB timing and power draw
• macro engines and memory constraints
• multiple connection modes (wired, 2.4G, BT)
• OS-level compatibility (Windows, macOS, Linux, consoles)

A QA plan should include:

• matrix scanning regression tests
• stuck-key / chatter detection tests
• battery and sleep/wake reliability tests (for wireless)
• firmware update rollback tests

---

14. Category Deep Dive: Headsets, Microphones, and Audio Accessories

14.1 What constitutes “good audio” (for gaming)

Gaming headsets are often evaluated on:

• positional imaging (left-right and front-back localization),
• clarity under effects-heavy mixes,
• microphone intelligibility,
• comfort for long sessions,
• wireless stability and range (for wireless models).

A practical decomposition of perceived sound quality:

• transducer frequency response,
• distortion at common listening levels,
• enclosure resonance and seal consistency,
• DSP equalization profiles,
• mic capsule quality and noise suppression tuning.

Because “sound quality” is subjective, a rigorous whitepaper approach is to:

• describe measurable variables,
• cite measurement protocols where possible,
• and separate taste-based preferences from engineering constraints.

14.2 Wireless headset constraints

Wireless headsets must manage:

• codec choices and latency,
• interference resilience (2.4 GHz congestion),
• battery runtime and charging behavior,
• multi-device handling.

A headset platform that “just works” tends to outperform one that only wins on spec lists.

---

15. Operations and Customer Experience as a Competitive Weapon

15.1 Why support quality matters more in peripherals than many categories

Peripheral customers often:

• troubleshoot aggressively,
• post detailed complaints publicly,
• influence others via community channels,
• and return quickly if the product is inconsistent.

Support quality therefore affects:

• refund rates,
• brand search results,
• conversion rate (CVR) through social proof,
• and long-term repeat purchases.

15.2 Logistics transparency and expectation management

An operational baseline for international DTC includes:

• region-specific shipping timelines,
• clear tracking status definitions,
• duties/taxes explanation by region,
• returns policy clarity,
• consistent customer communication templates.

---

16. Cybersecurity and Software Trust: From Incident Response to Competitive Advantage

Attack Shark’s published security update (Dec 2025) is an opportunity to establish a visible, repeatable security posture:

• a stable download portal,
• signed binaries,
• hash publication,
• and a simple disclosure policy.

A trust-first security posture is not only risk mitigation—it is marketing differentiation in a market where many challenger brands provide limited transparency.

Recommended public-facing artifacts:

• “How to verify our installer signature”
• “SHA-256 hashes for all downloads”
• “Release notes and known issues”
• “Security reporting channel and SLA”

Reference frameworks:

• NIST CSF
• OWASP Supply Chain Security

---

17. A Practical Evaluation Framework for Buyers and Reviewers

To reduce confusion and align with E‑E‑A‑T, brands should structure evaluation around:

17.1 Performance metrics (measurable)

For mice:

• report interval stability (ms) at each polling mode
• click latency (ms) under defined test conditions
• wireless packet loss under interference scenarios
• sensor stability (jitter, smoothing, CPI deviation)

For keyboards:

• scan rate and latency under NKRO conditions
• rapid trigger reset behavior under defined settings
• wireless stability and sleep/wake reliability

For headsets:

• wireless stability, dropouts, range
• mic intelligibility under noise suppression profiles
• comfort (weight, clamp force, pad material)

17.2 Trust metrics (operational)

• support response time (median, p90)
• return rate and defect rate by SKU and batch
• software update frequency (and changelog quality)
• security hygiene (signing, hashes, transparent incident handling)

---

Glossary

• HID: Human Interface Device (USB class for input devices).
• CPI/DPI: Counts per inch / dots per inch; often used interchangeably in mice marketing.
• Polling rate: How often the device reports to the host (Hz).
• Debounce: A filter window to prevent false switch triggers.
• LOD: Lift-off distance; the height at which the sensor stops tracking.

---

Additional Reference Links

• WIPO Global Brand Database (trademark lookups): WIPO BrandDB
• EU legislation portal (official texts): EUR-Lex