Restaurant Loyalty Token: ERC20 for Points, Tiers, and Free Dishes

A traditional loyalty program is a vendor SaaS — Loyverse, Square Loyalty, OpenTable Rewards. The vendor stores the points database. The restaurant pays per active customer. When a customer leaves and joins a competitor, the points die with the account.

An ERC20 loyalty token flips the model. The points live in the customer's own wallet. The restaurant operates the mint and burn keys but does not hold the balances. A chain of restaurants under one brand shares one contract, so a customer earns at the Defence branch and redeems at the Gulshan branch without integration headaches.

The companion piece on creating an ERC20 token in Remix walks through the base contract this builds on.

// Restaurant loyalty token — ERC20 with controlled mint and redeem
contract RestaurantPoints is ERC20, AccessControl {
    bytes32 public constant CASHIER_ROLE = keccak256("CASHIER_ROLE");
    bytes32 public constant KITCHEN_ROLE = keccak256("KITCHEN_ROLE");

    uint8 private constant DECIMALS = 0; // points are whole numbers

    event Earned(address indexed customer, uint256 amount, uint256 billRupees);
    event Redeemed(address indexed customer, uint256 amount, string item);

    constructor() ERC20("Tasty Points", "TASTY") {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
    }

    function decimals() public pure override returns (uint8) {
        return DECIMALS;
    }

    // 1 point per 100 rupees spent — cashier calls after the bill settles
    function earn(address customer, uint256 billRupees)
        external
        onlyRole(CASHIER_ROLE)
    {
        uint256 points = billRupees / 100;
        require(points > 0, "Loyalty: bill too small");
        _mint(customer, points);
        emit Earned(customer, points, billRupees);
    }

    // Kitchen confirms the dish was served, points are burned
    function redeem(address customer, uint256 amount, string calldata item)
        external
        onlyRole(KITCHEN_ROLE)
    {
        require(balanceOf(customer) >= amount, "Loyalty: not enough points");
        _burn(customer, amount);
        emit Redeemed(customer, amount, item);
    }
}

The two roles split the trust surface neatly. The cashier wallet sits inside the POS terminal at the front of house and can only mint. The kitchen wallet sits inside the kitchen display system and can only burn. If a cashier device is compromised, the attacker can inflate someone's points but cannot drain anyone's balance. If the kitchen device is compromised, the attacker can burn points but cannot mint to themselves.

The earn function takes the rupee amount of the bill, divides by the rate (100 in this example), and mints that many points to the customer's wallet. The rate is configurable per restaurant — a coffee shop might use 1 point per 50 rupees, a fine dining place might use 1 point per 500.

// Tier reading is a pure view function — no storage cost
function tier(address customer) external view returns (string memory) {
    uint256 bal = balanceOf(customer);
    if (bal >= 500) return "Diamond";
    if (bal >= 200) return "Gold";
    if (bal >= 50)  return "Silver";
    return "Regular";
}

// Tier specific discount lookup
function discountBps(address customer) external view returns (uint256) {
    uint256 bal = balanceOf(customer);
    if (bal >= 500) return 1500; // 15 percent
    if (bal >= 200) return 1000; // 10 percent
    if (bal >= 50)  return 500;  //  5 percent
    return 0;
}

The view function reads the balance and returns the tier name. No extra storage. No batch tier update job. A customer who crosses 200 points becomes Gold immediately, automatically, without any back end touching the database.

The POS reads discountBps at billing time and reduces the bill by the returned basis points. Diamond tier gets 15 percent off, Gold 10 percent, Silver 5 percent. The discount logic lives in the contract, not in the POS, so every branch applies the same rule.

// On chain redemption catalog — staff cannot redeem to off menu items
mapping(bytes32 => uint256) public itemPrice; // keccak256(name) => points

function setMenuItem(string calldata item, uint256 points)
    external
    onlyRole(DEFAULT_ADMIN_ROLE)
{
    itemPrice[keccak256(bytes(item))] = points;
}

function redeemMenu(address customer, string calldata item)
    external
    onlyRole(KITCHEN_ROLE)
{
    uint256 price = itemPrice[keccak256(bytes(item))];
    require(price > 0, "Loyalty: item not on menu");
    require(balanceOf(customer) >= price, "Loyalty: not enough points");
    _burn(customer, price);
    emit Redeemed(customer, price, item);
}

The admin defines a menu of redeemable items — a free coffee for 30 points, a dessert for 50, a main course for 200. The kitchen can only redeem items that exist in the menu mapping. Off menu redemption reverts. This removes one whole class of fraud where staff burns large amounts of points against a casual customer arrangement.

A customer can transfer points to a friend with a normal ERC20 send. Birthday gift, family allowance, friendly handover when a member moves cities — all handled by the standard transfer function. No SaaS feature request, no custom integration.

A restaurant chain with twelve branches deploys one contract. Every branch reads and writes the same balance map. Earning in Lahore and redeeming in Karachi is the default behavior, not a migration project. Even cross brand partnerships work — a coffee chain and a bookstore can accept each other's points by reading the partner's ERC20 balance.

The POS at checkout adds a wallet field to the bill. The customer either scans a QR from the restaurant app or types their wallet address. After payment confirms, the POS calls earn(customer, billRupees) through a relayer so the cashier device never holds gas. The customer sees a notification with the new balance.

The kitchen display reads the open order, sees the points the customer chose to redeem, and the kitchen wallet calls redeemMenu after plating. The order ticket and the burn happen in the same minute. Reconciliation is instant.

Run the deployment on Polygon, Base, or Arbitrum. A mint costs about a cent. A burn costs about a cent. A small restaurant chain with 500 customers earning twice a week pays under twenty dollars in gas per month — less than one SaaS loyalty seat.

We help restaurant chains, cafes, and subscription venues ship on chain loyalty programs, including the contract, the POS integration, the wallet inside the customer app, and the L2 deployment. The same pattern transfers to any business that wants a transferable, portable reward — salons, car washes, bookstores, and pharmacies have all been built on this shape.