Auteur

Contracts

Ethereum addresses, the permanent rewards controller, backing positions, and claims.

Auteur uses the $AUTEUR ERC-20 token, a rewards vault, its permanent controller, and a separate backing vault. Backing principal and reward funding are held in different contracts.

Mainnet deployments

Deployment parameters for the vault:

PropertyValue
NetworkEthereum Mainnet
Token0x90d54D77453286d30db891d729A0E18ba7081b07
Genesis timestamp1786302898
Genesis UTC2026-08-09 19:14:58 UTC
Epoch duration172800 seconds
Token unit10^18
Maximum settlement batch250 recipients

What is onchain

The vault stores:

  • the $AUTEUR amount claimable by each Ethereum address;
  • the total outstanding claim liability;
  • the amount credited in each epoch;
  • whether an epoch has been finalized;
  • processed batch identifiers;
  • default and overridden epoch ceilings;
  • settlement pause state.

What stays offchain

The contract does not store:

  • Farcaster or X identities;
  • Farcaster cast hashes or X post IDs;
  • recasts, curate commands, or other platform signals;
  • moderation decisions;
  • author/curator/backer reward role labels;
  • discovery evidence;
  • per-work reward calculations.

Before broadcasting, the backend aggregates the deterministic ledger by Ethereum recipient address. The vault only receives addresses and final amounts.

The backing vault separately stores position owners, auteur participant IDs, principal amounts, activation and exit epochs, and withdrawal state. It does not calculate or pay epoch rewards.

Public read methods

token() returns (address)
genesisStart() returns (uint64)
currentEpoch() returns (uint256)
epochCeiling(uint256 epochId) returns (uint256)
epochCredited(uint256 epochId) returns (uint256)
epochFinalized(uint256 epochId) returns (bool)
claimable(address account) returns (uint256)
totalOutstanding() returns (uint256)
availableSurplus() returns (uint256)
settlementsPaused() returns (bool)
admin() returns (address)
pendingAdmin() returns (address)

User method

claim() returns (uint256 amount)

claim() transfers the caller's entire accumulated claimable amount. It first clears the liability in contract state, then transfers $AUTEUR to the caller.

Funding and settlement methods

fund(uint256 amount)

creditRewards(
  uint256 epochId,
  bytes32 batchId,
  address[] recipients,
  uint256[] amounts
)

finalizeEpoch(uint256 epochId)

Anyone can call fund on the rewards vault after approving $AUTEUR. Funding remains available after the lock.

The operator calls creditRewards and finalizeEpoch on the controller, which calls the existing rewards vault. The vault's admin is the controller contract, not the operator wallet. Users still call claim() directly on the vault; no migration of existing claims is needed.

Reward credits are rejected when:

  • the epoch has not ended;
  • the epoch is already finalized;
  • the batch ID was already processed;
  • the batch exceeds 250 recipients;
  • the credit would exceed the epoch ceiling;
  • the vault lacks enough tokens to cover total outstanding claims;
  • settlement is paused.

Permanent controller and remaining trust

The controller took over from Epoch 9. It is not an upgradeable proxy. It exposes only the constrained vault operations needed for rewards:

  • credit recipients and finalize epochs from Epoch 9 onward;
  • set per-epoch ceilings between zero and 80M AUTEUR;
  • pause or resume new credits.

The 80M cap applies to the epoch's aggregate credits, not separately to each batch. Existing vault checks still reject current/future epochs, replayed batches, finalized epochs, and underfunded credits.

The old vault ABI still contains withdrawSurplus and admin-transfer methods. The controller exposes no way to call those methods, no arbitrary-call escape hatch, and no way to return vault administration to a wallet. Changing the controller's operator does not replace the controller or unlock the vault. Pausing settlement does not block existing claims or new funding.

This locks the withdrawal path, not the recipient list. The operator still controls the offchain list of reward recipients and can technically include an address it controls, within epoch limits. The contracts do not verify social identities, moderation quality, or the fairness of allocations.

Backing vault

back(uint256 auteurParticipantId, uint256 amount) returns (uint256 positionId)
cancelPendingBacking(uint256 positionId)
requestUnstake(uint256 positionId)
withdraw(uint256 positionId)
isActiveAt(uint256 positionId, uint256 epoch) returns (bool)

Approve the backing vault, not the rewards controller, when depositing backing principal. Deposits activate next epoch. Requesting unstake during Epoch N ends eligibility from N+1 and makes principal withdrawable from N+3.

Only the opening wallet can cancel, request exit, or withdraw a position. Its admin can pause new backing but has no principal-withdrawal method. Pausing new backing does not disable owner exits. See Backing an auteur for the full state table.

Verify contract state

With Foundry installed, anyone can read the deployed state through an Ethereum RPC:

export ETHEREUM_RPC_URL="https://your-ethereum-rpc.example"
export AUTEUR_TOKEN="0x90d54D77453286d30db891d729A0E18ba7081b07"
export AUTEUR_VAULT="0x665c9e6e9Cd2aB5c63C2c24BA511907D2449277F"
export AUTEUR_CONTROLLER="0x51097617062a82F0355Ab0f3025Ae2ECdD1549fd"
export AUTEUR_BACKING_VAULT="0x6b9f350Bc5868ada95454FfD58Db70ebf70a84Dc"

cast call "$AUTEUR_VAULT" "admin()(address)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_CONTROLLER" "vault()(address)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_CONTROLLER" "MAX_EPOCH_REWARDS()(uint256)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_BACKING_VAULT" "totalPrincipal()(uint256)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_VAULT" "token()(address)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_VAULT" "genesisStart()(uint64)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_VAULT" "currentEpoch()(uint256)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_VAULT" "totalOutstanding()(uint256)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_VAULT" "availableSurplus()(uint256)" \
  --rpc-url "$ETHEREUM_RPC_URL"

cast call "$AUTEUR_TOKEN" "balanceOf(address)(uint256)" "$AUTEUR_VAULT" \
  --rpc-url "$ETHEREUM_RPC_URL"

To inspect one recipient:

cast call "$AUTEUR_VAULT" "claimable(address)(uint256)" 0xRECIPIENT \
  --rpc-url "$ETHEREUM_RPC_URL"

The vault's admin() should equal the controller address. The controller's vault() should point back to the rewards vault. MAX_EPOCH_REWARDS() is 80000000000000000000000000 in base units.

On this page