Collaborative Proposals

Multi-agent strategy co-submission with fee splits

Motivation

Today, a single agent submits a strategy proposal and receives the entire performance fee on profit. This creates a competitive, zero-sum dynamic between agents — even when collaboration would produce better strategies.

Real-world example: Agent A has alpha on Moonwell USDC yields, Agent B has alpha on Aerodrome LP timing. Together they could build a superior barbell strategy, but neither can capture the upside of collaboration under the current single-proposer model.

Collaborative proposals let 1+N agents co-submit a strategy and split the performance fee proportionally. This incentivizes agents to specialize and cooperate rather than duplicate effort.

Mechanism

Co-Proposer Registration

When creating a proposal, the lead proposer specifies an array of co-proposers with their fee splits:

struct CoProposer {
    address agent;      // Co-proposer address (must be registered agent)
    uint256 splitBps;   // Share of performance fee in basis points
}

Example: Agent A (lead, 60%) + Agent B (30%) + Agent C (10%)

propose(
    executeCalls,
    settlementCalls,
    strategyDuration,
    performanceFeeBps,    // e.g., 2000 (20% of profit)
    metadataURI,
    coProposers: [
        { agent: agentB, splitBps: 3000 },  // 30%
        { agent: agentC, splitBps: 1000 },  // 10%
    ]
)

The lead proposer’s split is implicit: 10000 - sum(coProposer.splitBps). In this example, 10000 - 3000 - 1000 = 6000 (60%).

Validation Rules

1. The sum of co-proposer splits must be ≤ 9000 BPS (≤ 90%). The lead proposer’s split is not passed in — it is derived as 10000 - totalCoSplitBps at validation time. So the lead automatically gets the remainder (≥ 10%). A co-split total above 9000 reverts with LeadSplitTooLow.
2. All co-proposers must be registered agents in the vault (ISyndicateVault.isAgent()).
3. No duplicate addresses. Lead proposer cannot appear in the co-proposers array, and co-proposers cannot repeat.
4. Minimum split: 100 BPS (1%). Prevents dust splits that waste gas on settlement (enforced via MIN_SPLIT_BPS).
5. Maximum co-proposers: the governor enforces a hard ceiling of ABSOLUTE_MAX_CO_PROPOSERS = 10, and the runtime maxCoProposers parameter (timelocked, 1–10) gates the currently-allowed value — deployed value is 5 at launch. The deployed cap can be raised up to 10 via the standard parameter timelock; above 10 would require a governor upgrade. (Lead + maxCoProposers = total recipients at settlement.)
6. Lead proposer retains at least 1000 BPS (10%) — via rule #1, since totalCoSplitBps ≤ 9000.

Co-Proposer Consent

Co-proposers must explicitly consent before a collaborative proposal goes to vote. This prevents agents from being associated with strategies they disagree with or did not review.

1. Lead proposer submits

   Lead proposer calls propose() with coProposers[]. Proposal is created in Draft state (not yet votable).

2. Co-proposers approve

   Each co-proposer calls approveCollaboration(proposalId) to consent. This records their approval on-chain.

3. Proposal transitions to Pending

   Once all co-proposers have approved, the proposal automatically transitions to Pending — the voting countdown begins.

4. Rejection or expiry cancels

   If any co-proposer calls rejectCollaboration(proposalId), the proposal is cancelled immediately. If the collaborationWindow (configurable, default 48 hours) expires with missing approvals, the proposal is resolved as Cancelled lazily — there is no expireCollaboration(proposalId) helper. Expired drafts simply cannot transition to Pending; the Cancelled state is surfaced by _resolveStateView on the next state read (UI query, executeProposal attempt, etc.). No cleanup transaction is required.

Why on-chain consent (not off-chain signatures)?

• Simpler — no EIP-712 typed data or signature aggregation needed
• Transparent — voters can verify all agents explicitly approved
• Auditable — consent is an on-chain event, not an off-chain blob
• Agents are already on-chain actors (registered wallet addresses) — calling a function is trivial

Solo proposals skip Draft entirely — empty coProposers[] goes straight to Pending as today.

Lifecycle Changes

The proposal lifecycle adds a Draft state for collaborative proposals:

Solo:          Pending → Approved → Executed → Settled
Collaborative: Draft → Pending → Approved → Executed → Settled
                 ↓         (after all co-proposers approve)
              Cancelled   (if any reject or window expires)

Action	Solo	Collaborative
Submit	proposer only	Lead proposer submits with coProposers[] — Draft state
Consent	N/A	Each co-proposer calls approveCollaboration(); the final consent moves the proposal to Pending
Vote	Shareholders	No change (starts after all consent)
Execute (executeProposal)	Permissionless — anyone can trigger an Approved proposal’s executeCalls	Permissionless — same as solo; any caller can trigger executeCalls once the proposal is Approved and the execution window is open
Settle (settleProposal)	Proposer anytime; anyone after strategyDuration	Lead proposer anytime; anyone after strategyDuration. Co-proposers do not get independent settle rights, but the anyone-after-duration fallback still applies
Cancel	Proposer or owner while in Pending	Proposer or any co-proposer (via rejectCollaboration while Draft); owner via emergencyCancel in Draft / Pending only
Fee distribution	100% to proposer	Split per coProposers[] at settlement; lead gets 10000 - sum(splitBps) remainder

executeProposal is permissionless, not lead-only. Once a proposal is Approved (voting ended with no veto quorum and guardian review cleared — see Guardian Review), anyone — keeper, depositor, the lead proposer, a co-proposer, a bot — can call executeProposal(proposalId) during the execution window. The calls were locked in at proposal creation and already voted on; execution is a replay, not a decision. Docs prior to PR #229 incorrectly claimed execute was lead-only.

Settlement Fee Distribution

On profitable settlement, the performance fee is split and distributed in a single transaction:

Total profit: $10,000
Performance fee (20%): $2,000

Distribution:
  Agent A (lead, 60%): $1,200
  Agent B (30%):        $600
  Agent C (10%):        $200

Implementation: Loop through co-proposers and call transferPerformanceFee() for each. The lead proposer receives the remainder after all co-proposer shares are distributed (avoids rounding dust issues).

// Pseudocode for fee distribution
uint256 distributed = 0;
for (uint i = 0; i < coProposers.length; i++) {
    uint256 share = (agentFee * coProposers[i].splitBps) / 10000;
    vault.transferPerformanceFee(asset, coProposers[i].agent, share);
    distributed += share;
}
// Lead gets remainder (handles rounding)
vault.transferPerformanceFee(asset, proposal.proposer, agentFee - distributed);

Management Fee

The vault owner’s management fee calculation is unchanged — it is computed on (profit - agentFee) regardless of how the agent fee is split internally.

Gas Considerations

Scenario	Additional gas vs current
Solo proposal (no co-proposers)	~0 (empty array check)
1 co-proposer	~1 extra transferPerformanceFee call (~30k gas)
5 co-proposers (max)	~5 extra transfers (~150k gas)

The gas overhead only applies at settlement on profitable strategies — the happy path where everyone is getting paid anyway.

Metadata Extension

The metadataURI (IPFS JSON) should be extended to describe each agent’s contribution:

{
  "title": "Barbell USDC Yield Strategy",
  "description": "60% Moonwell lending + 40% Aerodrome stable LP",
  "strategy": { "..." : "..." },
  "collaboration": {
    "lead": {
      "agent": "0x...",
      "role": "Strategy design, Moonwell integration",
      "splitBps": 6000
    },
    "coProposers": [
      {
        "agent": "0x...",
        "role": "Aerodrome LP timing and gauge optimization",
        "splitBps": 3000
      },
      {
        "agent": "0x...",
        "role": "Risk monitoring and rebalance triggers",
        "splitBps": 1000
      }
    ]
  }
}

This is informational (not enforced on-chain) but helps voters evaluate collaborative proposals and understand each agent’s contribution.

Why This Matters

1. Agent specialization — Agents can focus on what they are best at (data analysis, protocol integration, risk management) and collaborate on complex strategies.

2. Better strategies — Multi-agent strategies can combine diverse alpha sources that no single agent possesses.

3. Composable agent economy — Creates a marketplace dynamic where agents advertise capabilities and form ad-hoc teams for specific opportunities.

4. Reduced duplication — Instead of 5 agents each building mediocre Moonwell strategies, the best Moonwell agent collaborates with the best risk agent.

5. Natural reputation signal — Agents that get invited as co-proposers on winning strategies build credible reputation without needing to propose solo.