Retroactive vesting overlay

Last updated Jun 14, 2026

Impose vesting on previously-issued, fully-vested shares. Requires stockholder consent. Useful in cofounder departures and post-financing cleanups.

Trigger

A founder grant is fully vested but the team wants protection going forward.

Call sequence

1. Create the overlay

POST /v1/vesting_overlays  { entity, grant, schedule }

2. Run stockholder consent

POST /v1/approvals  { kind: 'majority_written_consent', actions: [{ kind: 'apply_overlay', overlay }] }

3. Apply

POST /v1/vesting_overlays/{id}/apply

Idempotency

Overlay creation idempotent on `(entity, grant, schedule.hash)`.

Webhooks

Errors

Why VestingOverlay instead of amendGrant?

amendGrant mutates the underlying grant. That works when the original grant carried a vesting schedule and the amendment adjusts it (acceleration clause, schedule extension). But for retroactive vesting on founder stock issued without vesting, mutating the grant would:

• Lose the FSPA's no-vesting-at-issuance provenance.
• Make the original 83(b) (filed against unvested issuance) inconsistent with the new state.
• Corrupt the audit trail — the share ledger entry was created on the premise of immediate ownership.

VestingOverlay is purpose-built for this case: the original records remain intact; the overlay layers cleanly on top.

83(b) implications

Imposing vesting on previously-unvested stock is a §83 transfer event with different tax treatment than the original issuance. The recipient must decide whether to:

• file_new_83b — file a fresh 83(b) within 30 days of overlay effective_date. Required if the original 83(b) cannot be argued to cover the overlay (the conservative default).
• rely_on_original — rely on the original 83(b) to cover the overlay (uncommon and aggressive — needs counsel sign-off).
• decline_no_filing — defer; the overlay still binds but the tax outcome is suboptimal.

The decision is captured on the overlay creation request and surfaces in the amendment Document the founder counter-signs.

POST /v1/entities/ent_Nq3KcAbc/vesting_overlays
Idempotency-Key: <uuid>
{
  "ledger_entry_id": "led_M8sNxK2f",
  "grant_id": "grt_C1pT6yWh",
  "vesting_schedule": {
    "cliff_months": 12,
    "total_months": 48,
    "granularity": "monthly",
    "commencement_date": "2026-05-01"
  },
  "authorizing_resolution_id": "res_LqGcSdRb",
  "tax_election_acknowledgement": {
    "acknowledged_implications": true,
    "decision": "file_new_83b"
  },
  "effective_date": "2026-05-01"
}

Matter renders an FSPA Amendment Document (type: eighty_three_b_amendment) describing the new schedule + tax decision; the Document is sent to the founder for counter-signature via a SigningEnvelope.

Cap-table reads with overlay-aware vesting

Cap-table queries that opt in to the overlay surface vested vs unvested counts that respect the overlay's schedule. Without the expand, the query falls back to the underlying Grant's schedule (which has no vesting).

GET /v1/entities/ent_Nq3KcAbc/cap_table?expand[]=vesting_overlays&as_of=2027-05-01

{
  "object": "cap_table",
  "as_of": 1809484800,
  "stakeholders": [
    {
      "stakeholder_id": "stk_founder",
      "holdings": [
        {
          "share_class_id": "cls_common",
          "shares": 8000000,
          "vested_shares": 2000000,
          "unvested_shares": 6000000
        }
      ]
    }
  ]
}

At month 12 + 1 day after effective_date, the cliff releases — 25% of the underlying grant becomes vested. Each subsequent month adds 1/48th.

Related

• Issue a SAFE — the SAFE flow is what typically triggers the need for retroactive vesting (investor condition).
• Handle a cofounder departure — the inverse case, with mutual release.
• Run a board consent — authorising primitive for the overlay.