wormhole/whitepapers/0004_message_publishing.md

# Message Publishing

[TOC]

## Objective

To specify the mechanics and interfaces for publishing messages over Wormhole.

## Background

The original Generic Message Passing design doc describes the format of Wormhole messages, however, the way messages are
published needs to be defined clearly for chain endpoints to be built.

## Goals

* Specify an interface for posting messages.
* Specify a fee model for message posting.

## Non-Goals

* Dynamic spam protection.
* Distribution of fees.

## Overview

The core Wormhole contracts on every chain will have a method for posting messages to Wormhole, which will emit an event
that needs to be observable by guardians running a full node on a given chain.

The fees will be payable in the respective chain's native currency. Fees can be
claimed by the protocol and collected in a fee pool on Solana where they can be distributed according to protocol rules.

## Detailed Design

Wormhole core contracts have a `postMessage` method which can be used by EOAs (externally owned accounts) or SCs (smart
contracts)
to publish a message via Wormhole.

This method has to perform verification on the payload for the maximum size limitation of **750 bytes**. The message
should be emitted such that it can be picked up by guardians in a way that allows offline nodes to replay missed blocks.

The Wormhole contract will also need to make the emitter of the published message available to the guardians. The
emitter is either a parameter to the postMessage method if the chain allows proving that the caller controls or is
authorized by said address (i.e. Solana PDAs), or it is the sender of the transaction.

Additionally, the Wormhole contract will keep track of a sequence number per emitter that is incremented for each
message submitted.

The timestamp is derived by the guardian software using the finalized timestamp of the block the message was published
in.

When a message is posted, the emitter can specify for how many confirmations the guardians should wait before an
attestation is produced. This allows latency sensitive applications to make sacrifices on safety while critical
applications can sacrifice latency over safety. Chains with instant finality can omit the argument.

**Fees:**

In order to incentivize guardians and prevent spamming of the Wormhole network, publishing a message will require a fee
payment.

This fee is supposed to be paid in any of the chain's native fee currencies when publishing a message. This assumes that
anyone sending a transaction is already required to hold such assets in order to make the transaction publishing the
message, and that the fee will therefore not negatively affect usability of the bridge.

The fee is defined by governance using the `SetMessageFee` VAA. The fees set are denominated in the respective chains
native currency. Each chain's Wormhole program is supposed to use an on-chain price oracle (e.g. a uniswap pool TWAP or
Pyth price feed)
Fees are set per chain to allow the protocol to take into consideration the effort required to keep the chain's nodes
online and account for spam attacks.

Fees will be collected in a wallet that is controlled by the Wormhole contract, governance or a more automated mechanism
to be implemented in a later design doc will be able to produce a `TransferFees` which will allow to move the collected
fee tokens to a specified address. In case there is a widely accepted token bridge, this mechanism might be extended to
bridge tokens back to the chain where the governance and staking contracts are located for them to be distributed there.

### API / database schema

Proposed bridge interface:

`postMessage(bytes payload, u8 confirmations)` - Publish a message to be attested by Wormhole.

`setFees(VAA fee_payload)` - Update the fees using a `SetMessageFee` VAA

`transferFees(VAA transfer_payload)` - Transfer fees using a `TransderFees` VAA

---

**Payloads**:

The payloads follow the governance message format.

SetMessageFee:

```
// Core Wormhole Module
Module [32]byte = "Core"
// Action index (3 for Fee Update)
Action uint16 = 3
Chain uint16
// Message fee in the native token
Fee uint256
```

TransferFees:

```
// Core Wormhole Module
Module [32]byte = "Core"
// Action index (4 for Fee Transfer)
Action uint16 = 4
Chain uint16
// Amount being transferred (big-endian uint256)
Amount uint256
// Address of the recipient. Left-zero-padded if shorter than 32 bytes
To [32]uint8
```

## Caveats

A governance decision is required for the collection of fees. This means a lot of manual intervention in the
distribution of fees to stakers and guardians. The lack of a token bridge makes it hard to automate this in the early
days of the protocol. Also, a transfer primitive is unlikely to support token bridges (which may require smart contract
calls), so a contract will be required.

## Security Considerations