Network

Batching & Gasless

Two protocol-wide capabilities cut across every feature: batching many actions into one transaction, and letting a relayer pay gas on a user's behalf.

Bulk operations (multicall)

multicall(bytes[] calls) returns (bytes[] results)

multicall delegatecalls each entry back into the contract, so the acting address is preserved and every entry is authorised on its own. Any revert bubbles up and aborts the whole batch. Most operations batch freely — profile data, graph edges, posts, community posts, reactions with tips, community admin — so a client can, for example, follow ten accounts or post a gallery in a single transaction.

Paid operations (createProfile, setName, setCommunityName, createCommunity) are not batchable through multicall — they are sent on their own so fee accounting stays exact-match. A relayer may still batch many users' signed calls together (see below).

Gasless meta-transactions

executeSigned(address signer, bytes data, uint256 deadline, bytes sig)

A single generic entry point lets any function be called by a relayer while a user only signs — no per-function signed twin, keeping bytecode small.

  • data is an ABI-encoded call to any function of the contract.
  • The user signs an EIP-712 Execute(signer, data, nonce, deadline); the nonce is nonces[signer]++.
  • The contract verifies the signature — ERC-1271 first when the signer has code, then plain ECDSA — then sets a transient sender, self-calls data, and clears it. Every function resolves the actor through _msgSender(), so it works identically for direct and relayed calls. This means smart-contract wallets and EIP-7702 delegated EOAs work out of the box.
  • Fee-bearing calls stay payable by the relayer; fees still go to the treasury.
  • Re-entrancy is blocked: executeSigned reverts if a meta-tx is already in flight or if called by the contract itself, so nothing can swap the actor mid-call.

A signed multicall combines both: many actions authorised by one signature, submitted and paid for by a relayer.

Composable return values

buzz, communityBuzz and registerMedia return the ids they create, so another contract can call Buzzer and immediately use the resulting bid or fileId in the same transaction — social actions compose on-chain, not just off it.