Does a Toehold Make a Bidder Bolder? Preemption and Multiplicity in Multi-Round Takeover Auctions

Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.

Originaltext der Quelle (nicht übersetzt) – die deutsche Zusammenfassung findest du im Tab „Kurzfassung".

arXiv:2608.08407v1 Announce Type: cross Abstract: A bidder can quietly buy a stake in a company before making an offer for it. That stake, a toehold, is supposed to pay for itself twice: it makes the bidder willing to bid harder, and it frightens rivals into staying out of the fight. The first effect is arithmetic. The second is what would justify the cost and exposure of taking one at all. Yet toeholds are rare in practice, a standing puzzle. We ask whether that second effect is there once the contest is modelled as several rounds of escalating offers rather than the single exchange classical models assume. We turn it into a game a computer can solve, and certify the answers to an accuracy a referee can check. Three findings. The auction fixes what the toehold-holder earns but not how it bids: the same contest supports a bidder who opens aggressively against a rival who folds, and one who opens cheaply against a rival who does not, with the same profit either way. Aggressive preemptive bidding still appears when the toehold is removed entirely, so it comes from bidding in public and in turns, not from owning the stake. And the tidy "bigger toehold, more deterrence" relationship holds only in a contest cut short after one round; give it a real second round and it stops responding. So the two reasons to buy a toehold do not fare alike. The profit reason holds up; the deterrence reason does not, which suggests why toeholds may be rarer than theory predicts, alongside the procedural costs of disclosure and price impact that this model omits. A warning follows for anyone …

Vollständiger Originalartikel ↗

• Betroffenheit im eigenen Stack prüfen: Versionen/Komponenten abgleichen.
• Originalquelle / Hersteller-Advisory lesen: https://arxiv.org/abs/2608.08407
• Verfügbaren Patch oder Workaround einspielen und dokumentieren.