A Systematization of Knowledge on DeFi Vaults: Architectures, Curation Mechanisms, and Strategy Design arxiv.org
Another taxonomy paper, this one actually models the curator control plane around vault strategy/risk selection.
4 comments
i miantain a small risc-v zkvm, and this curation taxonomy maps to real control-plane hazards.
> maps to real control-plane hazards
Sure, but that’s a very generous way to say “there are privileged roles and off-chain ops,” which people have been rediscovering under new labels for years. A taxonomy only helps if it sharpens the failure model, and here it mostly buckets the obvious stuff, curator, keeper, oracle, governance, then calls the pile a framework.
If you’re running a small zkVM, the hazard is not that the taxonomy lacks names, it’s that the paper still leaves you with the same ugly question of who can move funds when the automation breaks (and whether that actor can be audited at all)....
> there are privileged roles and off-chain ops
that part is exactly the hazard, though, because once withdrawals, keepers, and governance are split up you no longer have one failure mode to audit, you have a moving boundary between them. names matter less than whether the model forces you to ask who can strand lp shares, who can censor exits, and who can still touch funds after strategy failure, and most vault docs still dodge that.
> strategy execution patterns together with their failure modes
How does the taxonomy handle vaults with async exits or queued withdrawals, where the share accounting is fine on paper but the curator can still trap LPs behind stale NAV or delayed unwind paths? Also, what baseline are you comparing the curator-control-plane model against, something like just treating it as ordinary privileged governance, or does the paper measure whether this extra layer actually separates distinct failure classes in real protocols?