---
eip: 3722
title: Poster
description: A ridiculously simple general purpose social media smart contract.
author: Auryn Macmillan (@auryn-macmillan)
discussions-to: https://ethereum-magicians.org/t/eip-poster-a-ridiculously-simple-general-purpose-social-media-smart-contract/6751
status: Stagnant
type: Standards Track
category: ERC
created: 2021-07-31
---

# Poster

## Abstract
A ridiculously simple general purpose social media smart contract.
It takes two strings (`content` and `tag`) as parameters and emits those strings, along with msg.sender, as an event. That's it.
The EIP also includes a proposed standard json format for a Twitter-like application, where each `post()` call can include multiple posts and/or operations. The assumption being that application state will be constructed off-chain via some indexer.

## Motivation
Poster is intended to be used as a base layer for decentralized social media. It can be deployed to the same address (via the singleton factory) on just about any EVM compatible network. Any Ethereum account can make posts to the deployment of Poster on its local network.

## Specification

### Contract

```solidity
contract Poster {

    event NewPost(address indexed user, string content, string indexed tag);

    function post(string calldata content, string calldata tag) public {
        emit NewPost(msg.sender, content, tag);
    }
}
```

### ABI
```json
[
    {
      "anonymous": false,
      "inputs": [
        {
          "indexed": true,
          "internalType": "address",
          "name": "user",
          "type": "address"
        },
        {
          "indexed": false,
          "internalType": "string",
          "name": "content",
          "type": "string"
        },
        {
          "indexed": true,
          "internalType": "string",
          "name": "tag",
          "type": "string"
        }
      ],
      "name": "NewPost",
      "type": "event"
    },
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "content",
          "type": "string"
        },
        {
          "internalType": "string",
          "name": "tag",
          "type": "string"
        }
      ],
      "name": "post",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    }
]
```

### Standard json format for Twitter-like posts

```json
{
  "content": [
    {
      "type": "microblog",
      "text": "this is the first post in a thread"
    },
    {
      "type": "microblog",
      "text": "this is the second post in a thread",
      "replyTo": "this[0]"
    },
    {
      "type": "microblog",
      "text": "this is a reply to some other post",
      "replyTo": "some_post_id"
    },
    {
      "type": "microblog",
      "text": "this is a post with an image",
      "image": "ipfs://ipfs_hash"
    },
    {
      "type": "microblog",
      "text": "this post replaces a previously posted post",
      "edit": "some_post_id"
    },
    {
      "type": "delete",
      "target": "some_post_id"
    },
    {
      "type": "like",
      "target": "some_post_id"
    },
    {
      "type": "repost",
      "target": "some_post_id"
    },
    {
      "type": "follow",
      "target": "some_account"
    },
    {
      "type": "unfollow",
      "target": "some_account"
    },
    {
      "type": "block",
      "target": "some_account"
    },
    {
      "type": "report",
      "target": "some_account or some_post_id"
    },
    {
      "type": "permissions",
      "account": "<account_to_set_permissions>",
      "permissions": {
        "post": true,
        "delete": true,
        "like": true,
        "follow": true,
        "block": true,
        "report": true,
        "permissions": true
      }
    },
    {
      "type": "microblog",
      "text": "This is a post from an account with permissions to post on behalf of another account.",
      "from": "<from_address>"
    }
  ]
}

```

## Rationale
There was some discussion around whether or not an post ID should also be emitted, whether the content should be a string or bytes, and whether or not anything at all should actually be emitted.

We decided not to emit an ID, since it meant adding state or complexity to the contract and there is a fairly common pattern of assigning IDs on the indexer layer based on transactionHash + logIndex.

We decided to emit a string, rather than bytes, simply because that would make content human readable on many existing interfaces, like Etherscan for example. This did, unfortunately, eliminate some of the benefit that we might have gotten from a more compact encoding scheme like CBOR, rather than JSON. But this also would not have satisfied the human readable criteria.

While there would have been some gas savings if we decided against emitting anything at all, it would have redically increased the node requirements to index posts. As such, we decided it was worth the extra gas to actually emit the content.

## Reference Implementation

Poster has been deployed at `0x000000000000cd17345801aa8147b8D3950260FF` on multiple networks using the [Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470). If it is not yet deployed on your chosen network, you can use the Singleton Factory to deploy an instance of Poster at the same address on just about any EVM compatible network using these parameters:

> **initCode:** `0x608060405234801561001057600080fd5b506101f6806100206000396000f3fe608060405234801561001057600080fd5b506004361061002b5760003560e01c80630ae1b13d14610030575b600080fd5b61004361003e3660046100fa565b610045565b005b8181604051610055929190610163565b60405180910390203373ffffffffffffffffffffffffffffffffffffffff167f6c7f3182d7e4cb876251f9ae1489975fdbbf15d9f35d393f2ac9b1ff57cec69f86866040516100a5929190610173565b60405180910390a350505050565b60008083601f8401126100c4578182fd5b50813567ffffffffffffffff8111156100db578182fd5b6020830191508360208285010111156100f357600080fd5b9250929050565b6000806000806040858703121561010f578384fd5b843567ffffffffffffffff80821115610126578586fd5b610132888389016100b3565b9096509450602087013591508082111561014a578384fd5b50610157878288016100b3565b95989497509550505050565b6000828483379101908152919050565b60006020825282602083015282846040840137818301604090810191909152601f9092017fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe016010191905056fea2646970667358221220ee0377bd266748c5dbaf0a3f15ebd97be153932f2d14d460d9dd4271fee541b564736f6c63430008000033`
>
> **salt:** `0x9245db59943806d06245bc7847b3efb2c899d11b621a0f01bb02fd730e33aed2`

When verifying on the source code on a block explorer, make sure to set the optimizer to `yes` and the runs to `10000000`.

The source code is available in the [Poster contract repo](https://github.com/ETHPoster/contract/blob/master/contracts/Poster.sol).


## Security Considerations
Given the ridiculously simple implementation of Poster, there does not appear to be any real security concerns at the contract level.

At the application level, clients should confirm that posts including a `"from"` field that differs from `msg.sender` have been authorized by the `"from"` address via a `"permissions"` post, otherwise they should be considerred invalid or a post from `msg.sender`.

Clients should also be sure to sanitize post data.

## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).