The signature stack lives in three files under lib/. IPortraitSigStruct defines a single struct, SigData, with six fields: action, target, targetType, version, params, and expirationTime. Every *For function in every registry builds one of these structs before asking PortraitSigValidator to verify it.

PortraitSigValidator.createMessage turns a SigData into a human-readable string. The string starts with a fixed introduction line, then lists the action, target, target type, version, a keccak hash of the full parameters, and the expiration time. The message is hashed with MessageHashUtils.toEthSignedMessageHash and then forwarded to the UniversalSigValidator for final verification. Because every field is visible in the message, a wallet popup shows the user exactly what they are approving before they sign.

The pattern repeats everywhere. PortraitIdRegistry uses it for RegisterFor, SetPrimaryPortraitFor, and TransferFor. PortraitAccessRegistry uses it for ToggleDelegateFor and ToggleDelegateRequestFor. PortraitNodeRegistry uses it for RegisterNodeToPortraitIdFor. PortraitNameRegistry uses it for RegisterNameFor. Every call hashes its own parameters into params, sets an action string that names the exact operation, and enforces a deadline.

struct SigData {
    string action;
    string target;
    string targetType;
    uint256 version;
    bytes32 params;
    uint256 expirationTime;
}

// Every registry builds one, e.g. in PortraitIdRegistry:
SigData memory data = SigData({
    action: "RegisterFor",
    target: CONTRACT_NAME,
    targetType: "Contract",
    version: VERSION,
    params: keccak256(abi.encodePacked(signer, owner, reservationHash, delegate, deadline)),
    expirationTime: deadline
});

portraitSigValidator.isValidSig(signer, data, sig);

PortraitSigValidator does not call ecrecover directly. It delegates to UniversalSigValidator, a full implementation of EIP-6492 bundled in EIP6492.sol. That means Portrait signatures work with EOAs, deployed smart contract wallets via ERC-1271, and counterfactual wallets that have not been deployed yet.

This is the piece that makes ERC-4337 account abstraction compatible with the protocol. An ERC-4337 smart account may not exist onchain when the user first signs. EIP-6492 handles that case: the signature includes the factory address and the calldata needed to deploy the wallet, so the validator can deploy the wallet in memory, call isValidSignature on it, and then revert the deployment to avoid side effects. If the wallet is already deployed, the validator skips the factory step and goes straight to ERC-1271.

The verification order inside UniversalSigValidator.isValidSigImpl is strict. It checks for the EIP-6492 suffix first, then tries ERC-1271 if there is contract code at the signer address, and only falls back to ecrecover for plain EOA signatures. That layering means a Portrait user can rotate from an EOA to a smart wallet without any migration on the protocol side. The same isValidSig call covers all three cases.

// PortraitSigValidator.isValidSig
string memory message = createMessage(data);
bytes32 ethSignedMessageHash = MessageHashUtils.toEthSignedMessageHash(
    abi.encodePacked(message)
);
return universalSigValidator.isValidSig(signer, ethSignedMessageHash, sig);

// UniversalSigValidator verification order:
// 1. EIP-6492 suffix → deploy counterfactual wallet, then ERC-1271
// 2. Contract code exists → ERC-1271 isValidSignature
// 3. No contract code → ecrecover (plain EOA)

The public repo can give the wrong first impression here. The identity side of Portrait Protocol was deployed on Base Sepolia, but the money path did not stay on the same chain. In portrait-api-backend, the contract helper maps the registry contracts to baseSepolia, then routes PortraitPaymentReceiverBase and PortraitPlusRegistryBase to Base mainnet and PortraitPaymentReceiverETH and PortraitPlusRegistryETH to Ethereum mainnet.

At the beginning, Portraits cost $10 per user. Both payment receiver contracts literally set paymentAmountUSD = 10, accept USDC, DAI, USDT, and ETH, and expose checkPaymentStatus(address) so the product can ask whether an address has already paid.

Later we introduced Portrait Plus. Instead of a simple paid flag, the Plus contracts store portraitIdToPortraitPlusExpiryTimestamp, so buying support time on Base or Ethereum extends an expiry window rather than flipping one boolean forever.

The frontend and backend did not merge that state in exactly the same place. In portrait-frontend, the public profile page reads PortraitPlusRegistryBase on Base mainnet directly to decide whether to show the Plus state. In portrait-api-backend, the real cross-chain merge lives in isPortraitPlus() and hasPortraitPlusTime(), which check Base first and then Ethereum before gating things like custom domains and page limits.

const contractToChain = {
  PortraitIdRegistry: 'baseSepolia',
  PortraitStateRegistry: 'baseSepolia',
  PortraitNameRegistry: 'baseSepolia',
  PortraitAccessRegistry: 'baseSepolia',
  PortraitNodeRegistry: 'baseSepolia',
  PortraitPaymentReceiverBase: 'baseMainnet',
  PortraitPaymentReceiverETH: 'ethereumMainnet',
  PortraitPlusRegistryBase: 'baseMainnet',
  PortraitPlusRegistryETH: 'ethereumMainnet',
}

const portraitPlusTimestampBase = await PortraitPlusRegistryBase.portraitIdToPortraitPlusExpiryTimestamp(portraitId)
if (now < portraitPlusTimestampBase) return true

const portraitPlusTimestampETH = await PortraitPlusRegistryETH.portraitIdToPortraitPlusExpiryTimestamp(portraitId)
if (now < portraitPlusTimestampETH) return true