{
  "@context": {
    "@language": "es-ES",
    "CIP100": "https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#",
    "CIP119": "https://github.com/cardano-foundation/CIPs/blob/master/CIP-0119/README.md#",
    "hashAlgorithm": "CIP100:hashAlgorithm",
    "body": {
      "@id": "CIP119:body",
      "@context": {
        "summary": "CIP119:summary",
        "rationale": "CIP119:rationale",
        "references": "CIP119:references"
      }
    }
  },
  "hashAlgorithm": "blake2b-256",
  "body": {
    "summary": "Scalus 2026: Maintenance, Dijkstra Readiness, Interoperability & Application Runtime",
    "rationale": "I vote YES.\n\nThis proposal feels much more reasonable than the previous version. The scope is smaller, the budget was reduced, and the risky parts like the L1 node and full L2 integration were removed.\n\nFor me, the strongest point is that this is not a new experiment from zero. Scalus already exists, has delivered before, and is used directly or indirectly by other Cardano tools and builders.\n\nI also think Dijkstra readiness matters. If Cardano is moving forward with new protocol capabilities, the developer infrastructure needs to be ready too.\n\nMy YES is based on the reduced scope, the delivery history, and the milestone-based accountability.",
    "references": []
  },
  "authors": [
    {
      "name": "drep15jspgw8ea9pw3w0fwyqam2lw58ulw7z6qhr8qyuah7j0yj962w7",
      "witness": {
        "witnessAlgorithm": "ed25519",
        "publicKey": "078c04a088ee52fe58d3257993ea6ec90f0b1dd59e4456a6b0e97e81f09525df"
      }
    }
  ]
}