Communication Playbook

Protocols for clear, consistent, and compliant messaging during crisis events.

This playbook outlines OLTA’s internal guidelines for communication during operational disruptions, protocol risks, or reputation-sensitive incidents. The goal is to ensure swift coordination, accurate messaging, and institutional-grade response integrity.


1. Objectives

  • Ensure timely and transparent communication to stakeholders.

  • Minimize misinformation or speculation.

  • Align external communication with internal remediation actions.

  • Satisfy compliance, legal, and investor expectations.


2. Core Roles & Responsibilities

Role
Responsibility

Risk Lead

Classifies the severity and notifies comms & legal teams.

Communications Officer

Crafts messaging (internal, public, partner-level).

Legal Counsel

Validates compliance, language, and liability exposure.

Core Contributor(s)

Provide technical context and validate facts.


3. Communication Tiers

Tier
Scenario
Channel(s)
Timeline

Internal Alert

Any disruption or flag raised

Core Contributor chat, internal Notion

≤ 30 min

Investor Notice

Potential fund impact (NAV, pricing, security)

Direct email, portal notice

≤ 4 h

Public Statement

Security breach, protocol incident

Twitter, Telegram, Linkedln, website banner.

≤ 6 h

Regulatory Reporting

If required (e.g., sanctions, KYC breach)

Legal counsel + official registry

Per legal timelines


4. Message Templates

Initial Update Template “We are aware of [issue] affecting [component]. Our team is investigating and will provide an update within [X hours]. Funds remain safe and no user action is required at this time.”

Post-Mortem Template “Following our investigation, [summary of issue]. A remediation plan has been implemented. Full technical details are available [link].”


5. Communication Do’s & Don’ts

Do:

  • Align messaging across all platforms

  • Disclose facts only, no speculation

  • Update periodically (e.g. every 4h during live incident)

Don’t:

  • Share unverifiable assumptions

  • Delay first update beyond the expected window

  • Overpromise resolution without engineering confirmation

Last updated