Tribute

// O(1)-STORAGE ON-CHAIN SUBSCRIPTION ENGINE · VYPER 0.4.3

A gas-optimized on-chain subscription engine. Most subscription systems store one slot per subscriber (mapping(address => uint256)) — a cost that grows linearly, so onboarding a million members means a million SSTOREs and a permanently larger state footprint. Tribute replaces that mapping with a single Merkle root: membership for any number of subscribers lives in one 32-byte slot, and each subscriber proves their own status on demand with a Merkle proof.

Vyper 0.4.3 Merkle Proofs Snekmate Moccasin Titanoboa ERC-20

View Source

O(1) Membership Storage

1 Merkle Root Slot

23 Tests Passing

0.4.3 Vyper

Mechanism

Membership is a Merkle tree whose root lives on-chain; payments and proofs do the rest. The contract never iterates a member set, so per-member cost is constant regardless of scale.

Single-slot membership — merkle_root: bytes32 commits to every subscriber and expiry; the owner refreshes it via update_root()
Self-proving status — check_status(addr, exp, proof) verifies leaf = keccak256(keccak256(abi_encode(addr, exp))) against the root via snekmate's merkle._verify
Pull-based renewals — renew(n) pulls n × price in a stablecoin to the treasury and emits RenewalRequested for an off-chain indexer
Grace period — active = block.timestamp <= exp + GRACE_PERIOD keeps paying users live across the gap between payment and the operator publishing the refreshed root

Security Design

The trust model is small by construction: the contract custodies no membership list and only the root-update authority is privileged. Renewal accounting is event-driven so the on-chain surface stays minimal.

Double-hashed leaves — keccak256(keccak256(...)) prevents second-preimage / intermediate-node forgery against the Merkle tree
Snekmate Merkle verification — proof checking uses the audited snekmate merkle_proof_verification module rather than hand-rolled logic
Owner-gated root updates — only the operator can call update_root(); no other path mutates membership state
Grace-period safety — a paid renewal can't be falsely deactivated during the publish window between payment and the next root
SafeERC20 pulls — stablecoin renewals tolerate non-standard tokens and route directly to the treasury

Test Coverage

23 tests passing against a titanoboa-driven Moccasin suite
Proof verification — valid proofs accepted, tampered proofs and wrong-expiry leaves rejected
Renewal flow — stablecoin pull accounting, event emission, and multi-period renew(n)
Grace logic — boundary tests around exp + GRACE_PERIOD across root-refresh windows

Key Features

O(1) membership storage — one 32-byte slot for ten or ten million subscribers
Merkle-proof self-verification, no on-chain member iteration
Pull-based ERC-20 stablecoin renewals surfaced as events for off-chain indexing
Grace period bridges the payment-to-root-publish window
Minimal trusted surface — only the root-update authority is privileged