dhawalorg
Research · ResearchWhy should I believe it?

Read the method, counterargument, limitations, and public record.

VIIIResearchQuestions · evidence · limits

What should I believe, and why?

Markets and systems work presented through one contract, so the question, hypothesis, result, counterargument, limitation, and reproduction status are visible before you open the full work.

Works
3
Markets
2
Sections
22
Contract
8 evidence fields

Evidence contract

A claim has to survive the whole path.

Read left to right. Every research object exposes all eight fields before asking you to trust the conclusion.
  1. 01QuestionWhat are we trying to explain?
  2. 02HypothesisWhat would we expect to find?
  3. 03MethodHow is the claim tested?
  4. 04ResultWhat did the evidence show?
  5. 05CounterargumentWhat is the strongest rival view?
  6. 06LimitationWhere does the evidence stop?
  7. 07VersionWhich published state is this?
  8. 08ReproductionCan the work be checked again?

Evidence-object library

Inspect the claim before opening the paper.

Every object uses the same contract: question, hypothesis, method, result, counterargument, limitation, version, and reproduction path.

Showing 3 of 3 research objects

01Descriptive resultMarkets / Data Investigation

The Calendar Is Not a Catalyst

A cross-asset investigation into magnitude, frequency, and the limits of seasonal evidence

Question
Does a recurring calendar-month average provide enough evidence to treat the month itself as a market catalyst?
Hypothesis
A seasonal pattern deserves attention only when magnitude, positive frequency, and sample size reinforce one another across related markets.
Method
Compare monthly mean returns, positive hit rates, and observation counts across the eight markets in the recurring seasonality dataset.
Result
The calendar is useful for framing a question, but no monthly average is sufficient on its own to establish a present-tense catalyst.
Counterargument
A recurring month can still provide useful conditional context when a current catalyst, explicit risk level, and independent evidence point the same way.
Limitation
Even the longest series in this investigation has only fifteen annual observations, and newer listings have fewer.
Version
1.0, 2026
02Testing protocolMarkets / Microstructure

Technical Analysis for Futures Traders

A quant-desk perspective on liquidity, order flow, and systematic edge in liquid futures markets

Question
Which technical-analysis primitives remain useful after futures microstructure, regime, execution, risk, and selection bias are made explicit?
Hypothesis
Technical analysis is most defensible as conditional information about structure, liquidity, and regime, not as a standalone pattern promise.
Method
Synthesize the methods across twenty-one chapters, then express quantitative claims as falsifiable, per-contract research protocols with out-of-sample requirements.
Result
The compendium establishes a testing and decision framework. It does not claim that every included setup has completed a unified empirical validation.
Counterargument
Experienced discretionary traders may extract value from judgment and practitioner convention without reducing each decision to a formal rule.
Limitation
Several claims remain working hypotheses or preliminary observations and require instrument-specific walk-forward testing with realistic execution costs.
Version
1.0, 2026
03Conceptual proposalDistributed Systems / P2P

Decentralized Community Communication

A peer-to-peer architecture for privacy-preserving, censorship-resistant social platforms

Question
Can real-time community communication work without a company-owned server storing, routing, and mediating the community?
Hypothesis
Peer discovery, distributed state, end-to-end encrypted media, and careful onboarding can support a usable community product without centralized message infrastructure.
Method
Specify the architecture across identity, peer discovery, gossip routing, WebRTC media, CRDT state, moderation boundaries, and onboarding.
Result
The paper provides a conceptual architecture and staged build path, not a measured implementation or adoption result.
Counterargument
Centralized infrastructure can make moderation, availability, recovery, and onboarding materially simpler for ordinary users.
Limitation
The design is pre-implementation and has not yet validated NAT traversal, abuse resistance, synchronization cost, or user retention in production.
Version
1.0, 2025
Reproduction
Implementation evidence is not yet available