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.
datais an ABI-encoded call to any function of the contract.- The user signs an EIP-712
Execute(signer, data, nonce, deadline); the nonce isnonces[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:
executeSignedreverts 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.