Why the protocol has no concept of product branding, and how distinct savings experiences are expressed as configuration rather than separate contracts.
The protocol itself has no concept of product branding whatsoever. isJoinable, boostMode, depositSchedule, and the admin template system are all generic knobs — none of them are tied to any specific product identity. That’s a deliberate, considered departure from an earlier model that used separate, isolated contracts per product, and it’s the single decision that makes everything else in this section possible.
What looks, from the outside, like distinct savings experiences — private versus joinable, disciplined recurring schedules, different lock and maturity behaviors — is really just different configuration of one generic SavingsVault primitive. None of it requires a separately deployed system, a separate audit, or a separate mental model for how funds move.
Product naming and default-configuration choices belong entirely to a layer above this specification — the dashboard and UX — not to the protocol itself. That means future products can be introduced exactly the same way today’s were: as a naming and default-configuration decision made at the product layer, never as new Solidity that needs its own review cycle.