Dual-vault architectures: deposit-facing vs deployment-facing
Dual-vault architectures: deposit-facing vs deployment-facing
A single vault that tries to do two jobs at once, holding depositors' capital and managing deployed credit exposure, tends to do both less well. The deposit-facing job wants stability, simplicity and predictable redemptions. The deployment-facing job wants the flexibility to move capital into specific, sometimes illiquid positions. Some vault designs split these into two vaults so each can be built for what it actually does.
How it works
The deposit-facing vault is the one depositors interact with. It issues the share token, handles subscriptions and redemptions, tracks value, and presents one understandable position. Its priorities are stability and legibility: a depositor should be able to see what they hold, what it's worth and when they can redeem, without needing to follow every underlying position.
The deployment-facing vault, or set of vaults, is where capital is put to work. It allocates capital from the deposit side into specific lending markets according to set risk parameters and an allocation policy. Its priorities are flexibility and control: sizing positions across markets, respecting concentration limits, and moving capital as positions mature, without disturbing what depositors see.
Between the two sits the allocation logic. Capital flows from the deposit side to deployments according to policy, and returns flow back. The two are connected by that controlled flow rather than merged into one balance sheet.
Why it matters
The split lets each side change without breaking the other. The deployment side can add position types and rebalance, while the deposit side stays stable and simple. It also makes the design easier to review: you can check the redemption rules on one side and the allocation limits on the other.
The trade-off is complexity. Two vaults and the logic between them mean more contracts to audit and more places where parameters matter, so independent audits and clear, on-chain limits on the allocation logic are worth looking for.
Where this shows up in Rekord
Rekord does not host its own vaults. It runs entirely on mature, independently audited third-party vault infrastructure, and how a vault separates deposits from deployment is one of the things worth understanding when evaluating any such infrastructure.