{"_id":"@eco-foundation/api-schemas","_rev":"13-e43d49c96a899fab411165f2df0a0f26","name":"@eco-foundation/api-schemas","dist-tags":{"latest":"0.13.0"},"versions":{"0.1.0":{"name":"@eco-foundation/api-schemas","version":"0.1.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.1.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"f1a7ce306c0f3dad3ddd233d4eee553236becf9a","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.1.0.tgz","fileCount":102,"integrity":"sha512-HWMamGzZRchYkQEzHnfPRvYnGSCt82D7AK3HUAR/Sn2jzyoql8r+VnDxl/fMrU6VjVEcyB0MiGkvssSDEUFVWw==","signatures":[{"sig":"MEUCIQD/GczmbYKuj2+u7bpqjAsLfLtgJWcKobb+9avcKMovYQIgZYcPfSyBxVOZUjFNqCNxtDdBBOKdq4As0oSjQKDQKXQ=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":519378},"main":"./dist/index.js","_from":"file:eco-foundation-api-schemas-0.1.0.tgz","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./openapi/v1.json":"./openapi/v1.json"},"scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","lint:check":"eslint \"src/**/*.ts\"","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"},"_resolved":"/private/var/folders/9_/7f92ts5x5dd8wbxyw0g26njw0000gn/T/64e5dd18b448c3bc9a89e9e62ab695fd/eco-foundation-api-schemas-0.1.0.tgz","_integrity":"sha512-HWMamGzZRchYkQEzHnfPRvYnGSCt82D7AK3HUAR/Sn2jzyoql8r+VnDxl/fMrU6VjVEcyB0MiGkvssSDEUFVWw==","_npmVersion":"10.9.0","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"zod":"4.4.3","@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.1.0_1787790170692_0.7010103851848755","host":"s3://npm-registry-packages-npm-production"}},"0.2.0":{"name":"@eco-foundation/api-schemas","version":"0.2.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.2.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"28a3c639947fd1bcf9ce594235eea76cfbe7cb72","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.2.0.tgz","fileCount":104,"integrity":"sha512-Bw76WQf+pwTPv+dEu+m72E6ULGMwCw1/cAcRsIvx0zPnEHwmtku+MD9rNcqZzUTTPSO2ELa5KPiaj7fMeDEV7A==","signatures":[{"sig":"MEQCIB+YU4WoqFJXULcGulD9rlCEUrBDnuigEzsChDk1EqcKAiB30O4dpmcWwhnLn3ZtBX5/ty8ftmj5+qcJOc6zzY1sGg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":532685},"main":"./dist/index.js","_from":"file:eco-foundation-api-schemas-0.2.0.tgz","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","lint:check":"eslint \"src/**/*.ts\"","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"},"_resolved":"/private/var/folders/9_/7f92ts5x5dd8wbxyw0g26njw0000gn/T/53f2973267ce694bc15c095ea06d558c/eco-foundation-api-schemas-0.2.0.tgz","_integrity":"sha512-Bw76WQf+pwTPv+dEu+m72E6ULGMwCw1/cAcRsIvx0zPnEHwmtku+MD9rNcqZzUTTPSO2ELa5KPiaj7fMeDEV7A==","_npmVersion":"10.9.0","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.2.0_1787815185523_0.43922833239370296","host":"s3://npm-registry-packages-npm-production"}},"0.3.0":{"name":"@eco-foundation/api-schemas","version":"0.3.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.3.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"3dbe9d688e620fa0f9ae4dfdf5c29903470065d3","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.3.0.tgz","fileCount":104,"integrity":"sha512-Caoj/rxB3i9pOEug/WMUUaQN+YJKgmxhSC20I04RicG/a+OVGYWvubZbCG5bkOoXGxWKv7zeLvgyJ995G4Iaog==","signatures":[{"sig":"MEYCIQC0cURYBPfuevqYmxN3eTiuPfMl1uiwVx2eq9uobFUSvQIhALBkYWw8xhKLZADmzHmCJqQ/FV9NfYeNQGKbFT9gip5q","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":536413},"main":"./dist/index.js","_from":"file:eco-foundation-api-schemas-0.3.0.tgz","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","lint:check":"eslint \"src/**/*.ts\"","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"},"_resolved":"/private/var/folders/9_/7f92ts5x5dd8wbxyw0g26njw0000gn/T/8be0fdab4f29287da7051b4680627f97/eco-foundation-api-schemas-0.3.0.tgz","_integrity":"sha512-Caoj/rxB3i9pOEug/WMUUaQN+YJKgmxhSC20I04RicG/a+OVGYWvubZbCG5bkOoXGxWKv7zeLvgyJ995G4Iaog==","_npmVersion":"10.9.0","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.3.0_1787820241281_0.09531119049967374","host":"s3://npm-registry-packages-npm-production"}},"0.4.0":{"name":"@eco-foundation/api-schemas","version":"0.4.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.4.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"6bf8866a92597358ed3b3558fd7198ccdc61231e","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.4.0.tgz","fileCount":104,"integrity":"sha512-trn+UgnMC6Jfv+9iDVJ9ijOjYjhfY/UPWjRxcDiGouWJuV24E5BsiY7UnVGjNJkv0ZZZ0dyghZecYXc/rZQtFw==","signatures":[{"sig":"MEUCIALs707tVOminAguHtAViRneGPIzgHuZSbIq6mmYkesTAiEAoLPAHnGYHF58xQTgvDwtMfiaQ4caGoUXRUWcNn7/FVM=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":579992},"main":"./dist/index.js","_from":"file:eco-foundation-api-schemas-0.4.0.tgz","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","lint:check":"eslint \"src/**/*.ts\"","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"},"_resolved":"/private/var/folders/9_/7f92ts5x5dd8wbxyw0g26njw0000gn/T/775e67694b6f041ad4df1cf369df5237/eco-foundation-api-schemas-0.4.0.tgz","_integrity":"sha512-trn+UgnMC6Jfv+9iDVJ9ijOjYjhfY/UPWjRxcDiGouWJuV24E5BsiY7UnVGjNJkv0ZZZ0dyghZecYXc/rZQtFw==","_npmVersion":"11.5.1","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"20.19.4","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.4.0_1787940507124_0.6041506046510001","host":"s3://npm-registry-packages-npm-production"}},"0.4.1":{"name":"@eco-foundation/api-schemas","version":"0.4.1","license":"MIT","_id":"@eco-foundation/api-schemas@0.4.1","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"a8379f4989334fa2b04b6c49f3de33a2e6753117","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.4.1.tgz","fileCount":104,"integrity":"sha512-QTx1SCrw2SYdfOIxfu8IXs1qskh42RoO71KXkURC0dNJheozl6hjwcWwLFZmGFkOfdu5frYSd8OZt6ufhNYUGA==","signatures":[{"sig":"MEUCIQD5fqbzLiXwRC+8dilmry1Btky14g8s+PSHbCGomJe1qQIgYFDZMpobImKcvPCzgQcL/XF622yrjStf3YjXXbyB92g=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":582373},"main":"./dist/index.js","_from":"file:eco-foundation-api-schemas-0.4.1.tgz","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"},"_resolved":"/private/var/folders/9_/7f92ts5x5dd8wbxyw0g26njw0000gn/T/68e28c54bd84cd2ce393c1b5cea5d760/eco-foundation-api-schemas-0.4.1.tgz","_integrity":"sha512-QTx1SCrw2SYdfOIxfu8IXs1qskh42RoO71KXkURC0dNJheozl6hjwcWwLFZmGFkOfdu5frYSd8OZt6ufhNYUGA==","_npmVersion":"11.5.1","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"20.19.4","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.4.1_1787959369790_0.476597401778865","host":"s3://npm-registry-packages-npm-production"}},"0.6.0":{"name":"@eco-foundation/api-schemas","version":"0.6.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.6.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"9fccafcec13d9fddb0c4c60d35e23769f7b0f453","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.6.0.tgz","fileCount":102,"integrity":"sha512-7uRU+Mv/rW3XgFlBMXbz7aCrL53p1qUVohWMIlvaIlzQgeleqPWBS0PmPH6miTilfc8Z7g6xQALFAxPReNod5A==","signatures":[{"sig":"MEQCICV0F1C4TmhFN+plQpA8IHTOdtHnNVdMUZ9rRcVERwCQAiBhGdUXa6z0htwFijZCwFzJgWcrj0B4FdspHVEn3xDuZQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":614192},"main":"./dist/index.js","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"gitHead":"d7e6f94d0c379173d9455fe31d88e707dd1a0959","scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","prepack":"pnpm run build","prepare":"pnpm run build","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com","approver":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}},"_npmVersion":"11.19.1","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"packageManager":"pnpm@10.16.1","devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.6.0_1788997991611_0.36384928157301855","host":"s3://npm-registry-packages-npm-production"}},"0.7.0":{"name":"@eco-foundation/api-schemas","version":"0.7.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.7.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"1b77cd0615f59c0653aba6e4aef31979842a7ca6","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.7.0.tgz","fileCount":104,"integrity":"sha512-Oai6+yYPflMn1Vq3SXxbB0fOHuFw2kw8rFWv5pFMyINPY1yB+eBrph4PbBXiEhH+PIFgitn6VWloVls0lE0lfw==","signatures":[{"sig":"MEUCIEj2Zl+PEK216mlyLQsEWAjaTn58ASlOezFCDQyw9fq/AiEAny0i1F2MZy6twlR56DrMzziKvw95PvTzQoaX46tpH2k=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":660404},"main":"./dist/index.js","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"gitHead":"5fbde9293b6112099561f6a534e9da9a9eae5ec8","scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","prepack":"pnpm run build","prepare":"pnpm run build","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com","approver":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}},"_npmVersion":"11.19.1","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"packageManager":"pnpm@10.16.1","devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.7.0_1789017220367_0.06916638235977124","host":"s3://npm-registry-packages-npm-production"}},"0.8.0":{"name":"@eco-foundation/api-schemas","version":"0.8.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.8.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"891b94d8457b985ef9d109c63ba6e2f247846c16","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.8.0.tgz","fileCount":104,"integrity":"sha512-3Z43/Mz7nbruajLx0JQfmfNMFnppUV3oOcJNMsW72vuInGn2rFha69X7L66G282qeL/IBfe8i1RgnqFdpGVIog==","signatures":[{"sig":"MEMCHyS2p+0tTG6fp4EhAVFdkkASUnOSMiobZmSYaqbBrkECIHsG7r/YipB8javL29hS4ZpCTwazcSWeRTnsontokxB7","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":661208},"main":"./dist/index.js","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"gitHead":"ebb1e417890908f6451fe56e791e98c4a03b5588","scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","prepack":"pnpm run build","prepare":"pnpm run build","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com","approver":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}},"_npmVersion":"11.19.1","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"packageManager":"pnpm@10.16.1","devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.8.0_1789417305665_0.12132943516137296","host":"s3://npm-registry-packages-npm-production"}},"0.9.0":{"name":"@eco-foundation/api-schemas","version":"0.9.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.9.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"8657302013c4ebd1d19316e8d152b085e96d080c","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.9.0.tgz","fileCount":104,"integrity":"sha512-S4ckaSH3Hn531KZNlLj1WAt4WsAp7bL8bAyd6wcqpqA7hujn66IBh5b9nYbpJRF/vc33RJRF1ScLf9Wq4MiYCA==","signatures":[{"sig":"MEUCIQCcqZI6jnFf2yCv2EQjYITP5hLgFHoCZgds+/IWBJTV2QIgZrUnvK+CzfEIOgEJJBYoDNs4CPe7x4yWkLjRuosII2A=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":717360},"main":"./dist/index.js","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"gitHead":"e89d88e70e4bba62cfc93390f922e1d5139f4048","scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","prepack":"pnpm run build","prepare":"pnpm run build","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com","approver":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}},"_npmVersion":"11.19.1","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"packageManager":"pnpm@10.16.1","devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.9.0_1789492859856_0.1702797002913754","host":"s3://npm-registry-packages-npm-production"}},"0.10.0":{"name":"@eco-foundation/api-schemas","version":"0.10.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.10.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"eaf6990ef8bd44688b86a5cf4c1f465c1ccdb49b","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.10.0.tgz","fileCount":106,"integrity":"sha512-lZ+R7Xb6TQz8Hy8HSjvJhD/DxEjqB8qOjVSzx7kkPDLd8DProXb2EtzbfanCoQuJuo9NQy3fmsJQ79SmEhbizg==","signatures":[{"sig":"MEUCIQCTEbsQEUyP5pJDjbMpGCgnVY8BUEpdmbSX2JOKUG/zpQIga1bbdkkunGwfb5YRqTboRvXAtHEzOGfB3iSHoS/kp00=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":736244},"main":"./dist/index.js","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"gitHead":"4f2cf68be2d140e20d338b26a238ede389837e3c","scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","prepack":"pnpm run build","prepare":"pnpm run build","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com","approver":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}},"_npmVersion":"11.19.1","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"packageManager":"pnpm@10.16.1","devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.10.0_1789759549334_0.04619301152449129","host":"s3://npm-registry-packages-npm-production"}},"0.11.0":{"name":"@eco-foundation/api-schemas","version":"0.11.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.11.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"29d2ee745c38446794fcc97bec068e80428af768","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.11.0.tgz","fileCount":106,"integrity":"sha512-zu8jxtUDevYpNzbKqQnFVno6iKFIL8eJaq2h5I/ISktrXljxQdOb7fwDVmBBBCUdaOwLV3FKQi7loyYZJhyLrw==","signatures":[{"sig":"MEUCIQDXv0j/cKwlwxm0dHpgHMSsprWs0WbJZ+LzwW4ow5+1BgIgHQ2YwRcnqyyd01fXQ6ZuU6suObeAQSgI8nz/Dpd6xZY=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":741676},"main":"./dist/index.js","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"gitHead":"de79db09cc119f98d833796a972cb3ab85ea3731","scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","prepack":"pnpm run build","prepare":"pnpm run build","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com","approver":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}},"_npmVersion":"11.19.1","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"packageManager":"pnpm@10.16.1","devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.11.0_1790001883281_0.03442042940735934","host":"s3://npm-registry-packages-npm-production"}},"0.12.0":{"name":"@eco-foundation/api-schemas","version":"0.12.0","license":"MIT","_id":"@eco-foundation/api-schemas@0.12.0","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"dist":{"shasum":"b51e5b320327e6a470d45c6c51e15d1d949be0cd","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.12.0.tgz","fileCount":106,"integrity":"sha512-tE0+bzk7b4PgnAXJzSpLR2Q8fjHYtS1od+FiOPo7W3GHrSppI2IJLEBFPjbrFZr4i/PjV3znqXHeBek20EP3Aw==","signatures":[{"sig":"MEQCIC1Oq5aTQXbchgLmnqqNBhewcEIUX2HpFOpRqSBxdFYPAiAqswucQIEP0zDZhWFJ2B+8mpsGz2sgEOl1tIkg+67O9Q==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":745287},"main":"./dist/index.js","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"gitHead":"3bdd37f408236e97dd1d39515121297df7fda419","scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","prepack":"pnpm run build","prepare":"pnpm run build","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com","approver":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}},"_npmVersion":"11.20.0","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"_nodeVersion":"22.11.0","dependencies":{"@scure/base":"^1.2.6","@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"_hasShrinkwrap":false,"packageManager":"pnpm@10.16.1","devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.3.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/api-schemas_0.12.0_1790194210492_0.9033061779554727","host":"s3://npm-registry-packages-npm-production"}},"0.13.0":{"_id":"@eco-foundation/api-schemas@0.13.0","dist":{"shasum":"849c0c87121b3a85a75702a60d1e966415e08157","tarball":"https://registry.npmjs.org/@eco-foundation/api-schemas/-/api-schemas-0.13.0.tgz","integrity":"sha512-j0cWqmM/N4gxhV2zGdU5IRvznehJ8Mw7rO3Y9Y/dvvmRgySX5rAHsnIeUyzUF6eecy95FfGk27KUri4hEWc/SQ==","fileCount":110,"unpackedSize":767548,"signatures":[{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEYCIQCoLKoDmytCUmSbvh9lf/SCsh4NikKrkXPrhBtGjevMsgIhAMFxuOP4DzlrpxRzl6tZ5z7BUorkn7yk+UI3Cx+z4KK9"}]},"main":"./dist/index.js","name":"@eco-foundation/api-schemas","types":"./dist/index.d.ts","engines":{"node":">=22.11 <23"},"exports":{".":{"types":"./dist/index.d.ts","default":"./dist/index.js"},"./testing":{"types":"./dist/testing/index.d.ts","default":"./dist/testing/index.js"},"./v1/types":{"types":"./dist/v1/types.d.ts","default":"./dist/v1/types.js"},"./fixtures/*":"./fixtures/*","./package.json":"./package.json","./v1/signature":{"types":"./dist/v1/signature.d.ts","default":"./dist/v1/signature.js"},"./openapi/v1.json":"./openapi/v1.json"},"gitHead":"c9e7c06dc679e8a7f6d75e9b48516ad405d68da4","license":"MIT","scripts":{"lint":"eslint \"src/**/*.ts\" --fix","test":"jest --config jest.config.ts","build":"rimraf dist && tsc -p tsconfig.build.json","verify":"pnpm run build && pnpm run lint:check && pnpm run test && pnpm run catalog:check && pnpm run openapi:check && pnpm run digest:check","prepack":"pnpm run build","prepare":"pnpm run build","lint:check":"eslint \"src/**/*.ts\"","canon:check":"scripts/check-vendored-signature-vectors.sh","catalog:lock":"pnpm run build && node scripts/lock-error-catalog.mjs","digest:check":"node dist/scripts/generate-build-digest.js --check","catalog:check":"node scripts/check-error-catalog.mjs","openapi:check":"node dist/scripts/generate-openapi.js --check","digest:generate":"pnpm run openapi:generate && node dist/scripts/generate-build-digest.js","openapi:generate":"pnpm run build && node dist/scripts/generate-openapi.js"},"version":"0.13.0","_npmUser":{"name":"carlosfebres","email":"carlosfebres97@gmail.com","approver":{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}},"_npmVersion":"11.20.0","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","directories":{},"maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"_nodeVersion":"22.11.0","dependencies":{"@scure/base":"^1.2.6","@noble/hashes":"^1.8.0"},"publishConfig":{"access":"public"},"packageManager":"pnpm@10.16.1","devDependencies":{"zod":"4.4.3","jest":"^29.7.0","viem":"^2.40.1","eslint":"^8.57.0","rimraf":"^5.0.7","ts-jest":"^29.1.2","ts-node":"^10.9.2","prettier":"^3.2.5","typescript":"^5.9.3","@types/jest":"^29.5.12","@types/node":"22.20.0","eslint-config-prettier":"^9.1.0","eslint-plugin-prettier":"^5.1.3","@typescript-eslint/parser":"^7.9.0","@typescript-eslint/eslint-plugin":"^7.9.0","eslint-plugin-simple-import-sort":"^12.1.1"},"peerDependencies":{"zod":"^4.4.0"},"peerDependenciesMeta":{"zod":{"optional":true}},"_npmOperationalInternal":{"host":"s3://npm-registry-packages-npm-production","tmp":"tmp/api-schemas_0.13.0_1790226267934_0.38912463863029645"},"_hasShrinkwrap":false}},"time":{"created":"2026-08-27T00:22:50.587Z","modified":"2026-09-24T05:04:28.225Z","0.1.0":"2026-08-27T00:22:50.859Z","0.2.0":"2026-08-27T07:19:45.710Z","0.3.0":"2026-08-27T08:44:01.455Z","0.4.0":"2026-08-28T18:08:27.316Z","0.4.1":"2026-08-28T23:22:49.970Z","0.6.0":"2026-09-09T23:53:11.708Z","0.7.0":"2026-09-10T05:13:40.483Z","0.8.0":"2026-09-14T20:21:45.790Z","0.9.0":"2026-09-15T17:21:00.005Z","0.10.0":"2026-09-18T19:25:49.435Z","0.11.0":"2026-09-21T14:44:43.367Z","0.12.0":"2026-09-23T20:10:10.633Z","0.13.0":"2026-09-24T05:04:28.070Z"},"license":"MIT","description":"Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco /v1 API","maintainers":[{"name":"mdavid123","email":"mdavid@eco.com"},{"name":"seveyeco","email":"matt@eco.com"},{"name":"paged","email":"dirkpage@hotmail.com"},{"name":"aleph2012","email":"satish@beam.io"},{"name":"carlosfebres","email":"carlosfebres97@gmail.com"}],"readme":"# @eco-foundation/api-schemas\n\nZod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for the Eco `/v1`\nAPI. The Zod schemas are the source of truth; everything else (OpenAPI, fixtures, plain types)\nis generated from or gated against them.\n\nToday the package covers **13 endpoints across 12 paths**, **40 error codes** (51 namespaced\nlegacy references), and **21 golden fixtures**.\n\n## Install\n\nWhile the package is 0.x, pin the patch range or the exact version:\n\n```json\n{\n  \"dependencies\": {\n    \"@eco-foundation/api-schemas\": \"~0.13.0\"\n  }\n}\n```\n\n**Never write `^0`.** npm resolves `^0.x` as `>=0.0.0 <1.0.0`, so it silently accepts every\nfuture breaking `0.y` — it is not a pin at all. Use `~0.13.0` or the exact `0.13.0`.\n\nA matching version string is not evidence of a matching artifact: also compare\n`V1_SCHEMA_DIGEST` (see [Invariants](#invariants-enforced-in-ci)). Two builds both called\n`0.4.0` — a registry copy and a `file:` tarball, say — can carry different schemas.\n\n`zod` is a peer dependency, and since `0.3.1` an **optional** one — required only if you import a\nzod-bearing entry point. Which case you are in is decided entirely by your imports; see\n[Consumers](#consumers).\n\n## Migrating 0.12.0 -> 0.13.0\n\n**BREAKING under 0.x semver only for exhaustive handling of `V1ErrorCode`.** Nothing on the wire\nthat `0.12.0` accepted is rejected and no response shape changes. The release adds one error code,\none config schema, and one fixture file for scheduled maintenance windows (PER-673).\n\n**`V1_SCHEMA_DIGEST` MOVES** to\n`e5a684f678f80135ddf7241029d965d2a206b3b573a9969ad1352610d1b4abc9`, because both digest inputs\nchanged (`errors/catalog.lock.json` gained one code and `openapi/v1.json` its `x-error-catalog`\nentry). Every consumer running `assertNoSkew` moves in the same rollout.\n\n**1. New error code `maintenance` (503, audience `all`, no legacy codes).** It is a planned stop,\ndistinct from `service-unavailable` (an outage). eco-router, eco-quotes and deposit-addresses\nreturn it from every quote-creating and address-creating endpoint while a configured window is\nactive, with `startsAt`/`endsAt` in the body and a `Retry-After` header. `V1ProblemSchema` now\nchecks a `maintenance` body's `status`/`type` against the catalog, and an exhaustive `switch`\nover `V1ErrorCode` stops compiling until it handles the new member. That is the breaking item.\n\n**2. New config schemas `MaintenanceWindowSchema` and `MaintenanceConfigSchema`** (on the `v1`\nnamespace, with types `MaintenanceWindow`, `MaintenanceConfig`, `MaintenanceConfigInput`). A\nwindow is `{ startsAt, endsAt, message }`: `startsAt` inclusive, `endsAt` exclusive, both\nISO-8601 UTC strings ending in `Z` with at most three fractional digits (offsets and impossible\ndates such as `2026-02-30` are rejected), `message` 1-200 characters and not blank (whitespace-only\nis rejected — it is echoed verbatim to partners), and `endsAt` must be after `startsAt`. `windows`\ndefaults to `[]`. Both schemas reject any key not in their shape (e.g. a `window` typo for\n`windows`) at parse time, naming the key — this is scoped to the raw input's own enumerable\nproperties, so a config object read through node-config (whose hidden, non-enumerable `get`/`has`/\n`util` helpers are unaffected) still parses. Overlapping windows are allowed; past windows are valid\n(services drop them at boot). **Quote the timestamps in YAML**: an unquoted\n`2026-10-04T02:00:00Z` is loaded as a `Date` and fails with \"quote it in YAML\". There is no\n`./v1/maintenance` subpath, because the schemas need zod anyway, so import them from the root\n`v1` namespace.\n\n**3. New fixture `fixtures/maintenance-boundaries.json`** (served by the existing `./fixtures/*`\nsubpath). Each entry service implements its own resolver (the package deliberately ships none)\nand asserts it against every vector: active when `startsAt <= now < endsAt`; with several\nactive, the latest `endsAt` wins and a tie goes to the first in the list;\n`retryAfterSeconds = max(1, ceil((endsAt - now) / 1000))`.\n\n**4. Consumers** pin `~0.13.0` (never `^0`) and re-run `assertNoSkew`. No golden fixture under\n`src/fixtures/v1` changed.\n\n**5. The `zod` peer range rises to `^4.4.0`** (from `^4.3.0`), still optional. The maintenance\nschemas' exported types (`MaintenanceWindowSchema`, `MaintenanceConfigSchema`) use\n`z.ZodPreprocess`, which zod only exports from 4.4 — on zod 4.3.x those `.d.ts` types silently\ncollapse to `any` under `skipLibCheck` (and fail `TS2724` without it). A consumer that imports\nzod-bearing entry points must upgrade to zod `^4.4.0`+ before adopting `0.13.0`; the two\nzod-free subpaths (`./v1/signature`, `./v1/types`) are unaffected.\n\n## Migrating 0.11.0 -> 0.12.0\n\n**Non-breaking for callers, a new version for consumers.** `GET /v1/intents/status` now accepts\na transaction hash from any supported VM in `sourceTxHash` and `destinationTxHash`:\n\n- EVM: `0x` + 64 hex (unchanged),\n- Tron: 64 hex without `0x`,\n- Solana: a base58 transaction signature (must decode to exactly 64 bytes).\n\nNew exports: `TxHash`, `TronTxId`, `SvmSignature`. `intentHash` is unchanged (`Bytes32`), and no\nresponse shape changed. New runtime dependency: `@scure/base` (base58 decoding).\n\nServers that parse this query with `IntentStatusQuerySchema` will now pass non-EVM hashes through\nto their lookup: make sure the lookup, its miss path and any cursor comparison handle a\ncase-sensitive base58 value (eco-router does this in the release that adopts 0.12.0).\n\n## Migrating 0.10.0 -> 0.11.0\n\n**BREAKING under 0.x semver** (breaking bumps the minor while the major is 0). One new fee\ntype, `cctp`, so the Circle CCTP fast-transfer fee a stitched quote forwards as the burn\n`maxFee` is never reported under `gateway`, which is the Circle Gateway (unified-balance mint)\nfee — two different Circle products. No request change; no response SHAPE change. Item 1 is the\nbreaking item: read it before bumping.\n\n**`V1_SCHEMA_DIGEST` MOVES** to\n`fc94f96a47a3de78249612d0472f3a91cc8217ba4829b2c5422f0baf87cf7fc6`; it was\n`fa55e655ef48bbc69a551e263c1bf80cc91e8b920f9f98c29cf9b62b01a53be9` on `0.10.0`. Every consumer\nrunning `assertNoSkew` moves in the same rollout.\n\n**1. `FEE_TYPES` gains `'cctp'`**; `FeeType`, `FeeTypeTolerant` and the zod-free `V1FeeType`\nfollow, so `FeeSchema.type` / `V1Fee.type` may carry the new literal. A 0.10.x reader parsing a\nresponse fee with the strict `FeeType` REJECTS it; one on `FeeTypeTolerant` receives\n`{ unknown: 'cctp' }` and keeps working; a reader that needs the literal bumps to `~0.11.0`.\nThis is the breaking item. The router validates every solver fee through the strict schema and\nDROPS an unparseable one, so a router still on `~0.10.0` publishes a stitched quote WITHOUT its\nCCTP fee row and under-reports the charge — roll the router before any solver emits `cctp`.\n\n**2. What each Circle type means**, now published on `FeeSchema.type`'s description: `gateway`\nis the Circle Gateway fee (per-domain base plus bps) on Gateway-funded routes; `cctp` is the\nCircle CCTP fast-transfer fee, bps of the burn amount, that a stitched quote forwards VERBATIM as\nthe `depositForBurn` `maxFee` — so it equals that argument in the route bytes and a consumer can\ncross-check the two. It is a ceiling (Circle's realized charge can only come in lower), so the\nproducer marks it `estimate: true`; the partner margin beside it (`protocol`) is exact and\n`estimate: false`. The other three types are unchanged.\n\n**3. Consumers** pin `~0.11.0` (never `^0`) and re-run `assertNoSkew`. `errors/catalog.lock.json`\nis unchanged (no new error code). `openapi/v1.json` is regenerated (the fee `type` enum plus its\nnew description). No golden fixture changes.\n\n## Migrating 0.9.0 -> 0.10.0\n\n**BREAKING under 0.x semver** (breaking bumps the minor while the major is 0). One new quote\ntype, `gateway-deposit`, for the Circle Gateway fast-deposit route the deposit-addresses\nservice requests through `POST /v1/quotes`. No response SHAPE change; one response-refinement\ncarve-out (item 3). Item 1 is the breaking item: read it before bumping.\n\n**`V1_SCHEMA_DIGEST` MOVES** to\n`fa55e655ef48bbc69a551e263c1bf80cc91e8b920f9f98c29cf9b62b01a53be9`; it was\n`bedfc6091a9af25adf1823740b6761f97bcb1927565bc3f226490bb2facda514` on `0.9.0`. Every consumer\nrunning `assertNoSkew` moves in the same rollout.\n\n**1. `QUOTE_TYPES` gains `'gateway-deposit'`**; `QuoteType`, `QuoteTypeTolerant` and the\nzod-free `V1QuoteType` follow, so `QuoteCoreSchema.type` / `V1QuoteCore.type` echo the new\nliteral. A 0.9.x reader parsing response `type` with the strict `QuoteType` REJECTS it; one on\n`QuoteTypeTolerant` receives `{ unknown: 'gateway-deposit' }` and keeps working; a reader that\nneeds the literal bumps to `~0.10.0`. The draft `/v1/routes` `swapTypes` enum widens too. This\nis the breaking item.\n\n**2. Request rules for `type: 'gateway-deposit'`**: three are in `QuoteRequestSchema`'s\nrefinement, 400 at the named path — `source.amount` REQUIRED (`gateway-deposit requires\nsource.amount`); `destination.amount` REJECTED (`gateway-deposit forbids destination.amount\n(the engine derives it)`); `destination.calls` REJECTED (the existing `destination.calls is\nonly valid with type custom (D7)`, literal unchanged). `destination.recipient` REQUIRED (a\nbase-schema field, required on every type since 0.9.0; for this type it is the final Gateway\nrecipient on the destination chain). `exact-in` and `custom` continue to ACCEPT a\n`destination.amount` (the router drops it); generalising the forbid is out of scope. The\nper-type rule is published on the field: `destination.amount` now carries the description\n`Required for exact-out. Rejected for gateway-deposit (the engine derives it). Not read for\nexact-in or custom.`, and `type` carries a description of the route. Solver preconditions\n(stated there, not as an error code): the destination must be an EVM chain for which the solvers\nhold a Circle Gateway wallet configuration (HyperCore destinations are refused) and\n`source.token` should be the source chain's USDC — any other token is priced only through the\nsolvers' stitched swap ladder and may be refused. A fleet-wide refusal reaches the caller as 502\n`solver-error` with the solver texts in `solverErrors[]`, not as 422 `no-route-found`.\n\n**3. `refineQuoteCore`'s sweep-4 ordering (`reward.deadline > route.deadline`) is NOT applied\nwhen `type === 'gateway-deposit'`** — on the envelope and on every `quotes[]` entry alike. The\nsolver's STITCHED Gateway-deposit template inverts the ordering on both legs by design (reward\nwindow 3600 s so refund eligibility opens early; route deadline 604800 s so fulfilment stays\nretryable); the DIRECT shape keeps the usual ordering. Both deadlines stay `UnixSeconds`. Every\nother type is unchanged and still strict; the carve-out is keyed on the type literal, never on a\nsame-chain or stitched predicate.\n\n**4. Response shape** for the type depends on the winning solver's destination balance, not on\nits role: DIRECT (one cross-chain intent, `execution.intent.route.destination ===\ndestination.chainId`, `route.portal` = the destination-chain Portal) or two-leg STITCHED\n(`execution.intent` = leg A, a same-chain local intent on the source chain that the funder\nfunds; `steps[].intents[]` carries leg C with role `stitched-destination`). Consumers must\naccept both. `expiresAt` is NOT the route deadline — read `execution.intent.route.deadline`.\n`execution.encodedRoute` remains absent (0.9.0 item 8 stands); re-encode from\n`execution.intent.route` when bytes are needed.\n\n**5. Consumers** pin `~0.10.0` (never `^0`) and re-run `assertNoSkew`. `errors/catalog.lock.json`\nis unchanged (no new error code — `no-route-found` and `invalid-api-key` already exist).\n`openapi/v1.json` is regenerated (the `type` enum plus the two descriptions). Two golden\nfixtures added — `quotes.create:request:gateway-deposit` and\n`quotes.create:response:gateway-deposit` (the producer's stitched shape with inverted\ndeadlines on both legs) — for 21 in total; both are in the §5 mandatory list.\n\n## Migrating 0.8.0 -> 0.9.0\n\n**BREAKING under 0.x semver** (breaking bumps the minor while the major is 0). Eleven wire\ncorrections from the /v1 API review, all in one release. Every renamed or removed field is a\n400 on the request side (every request object is strict) and simply absent on the response\nside. Read the whole list before bumping; the two structural items (7 and 8) need a code\nchange in every consumer.\n\n**`V1_SCHEMA_DIGEST` MOVES** to\n`bedfc6091a9af25adf1823740b6761f97bcb1927565bc3f226490bb2facda514`; it was\n`a61dfe727b15162f9097b421ca2f7660750e8cfad85ccf2d1c8dd8340207852a` on `0.8.0`. Every consumer\nrunning `assertNoSkew` moves in the same rollout.\n\n**1. `swapType` is `type`** on the request and the response. Values are unchanged\n(`exact-in`, `exact-out`, `custom`). Exports: `SWAP_TYPES`/`SwapType`/`SwapTypeTolerant`/\n`V1SwapType` are now `QUOTE_TYPES`/`QuoteType`/`QuoteTypeTolerant`/`V1QuoteType`. The draft\n`/v1/routes` response field `swapTypes` (a per-route capability list) keeps its name; only the\nquote request and response are renamed.\n\n**2. `kind` is `type` everywhere**: `fees[].type`, `steps[].type`,\n`execution.transaction.type` (`'evm' | 'svm'`, the discriminated-union key), and the\ndeposit-address create request, record and lookup filter (`type: 'solana' | 'gateway' |\n'gateway-erc20'`). Exports renamed accordingly (`FeeType`, `StepType`, `DepositAddressType`\nand their tuples/tolerant twins/zod-free aliases). The API now has exactly one discriminator\nname.\n\n**3. `funder` is `source.funder`**, and the response echoes it at `source.funder`.\n\n```diff\n {\n-  \"funder\": \"0x…\",\n-  \"source\": { \"chainId\": 8453, \"token\": \"0x…\", \"amount\": \"1043221\" },\n+  \"source\": { \"chainId\": 8453, \"token\": \"0x…\", \"amount\": \"1043221\", \"funder\": \"0x…\" },\n }\n```\n\nA root `funder` yields two issues: `unrecognized_keys` at path `''` and a missing\n`source.funder`. The address-family rule now reports at `['source', 'funder']`.\n\n**4. `dappId` is REQUIRED** on every quote request (400 at `['dappId']` when missing).\n\n**5. Response `destination.amount` is `destination.amountOut`.** `minAmountOut` is unchanged;\n`source.amount` and both request amounts are unchanged.\n\n**6. `steps[].tool` is `steps[].provider`.** `aggregator` is unchanged.\n\n**7. `relatedIntents[]` is gone; each step carries `intents[]`** with the FULL decoded intent:\n\n```json\n\"steps\": [{ \"type\": \"swap\", \"provider\": \"uniswap-v3\", \"…\": \"…\",\n  \"intents\": [{ \"role\": \"local\", \"intentHash\": \"0x…\",\n    \"intent\": { \"route\": { \"…\": \"…\", \"calls\": [ … ] }, \"reward\": { … } } }] }]\n```\n\n`intents` is required on every step and may be empty (a step realized by a not-yet-existing\nintent). Root `intentHash` stays. The quote signature (F3) commits to the root hash plus every\nstep intent hash — use the new `quoteIntentHashes(quote)` to collect them; the builder still\nlower-cases, dedupes and sorts. Exports: `RelatedIntentSchema`/`V1RelatedIntent` are\n`StepIntentSchema`/`V1StepIntent`.\n\n**8. `visibility`, `guarantee`, `execution.encodedRoute` and `execution.encodedReward` are\nremoved**, and `execution.intent.route.calls` is REQUIRED and non-null. Visibility was never a\ncaller's knob: how a quote is routed is a router policy decision, and the funding function was\nnever visibility's to choose — on EVM the funding transaction is always `Portal.publishAndFund`;\non Solana it is one `Portal.fund` instruction. The route preimage is therefore never hidden.\n`options.visibility` is a 400; `Visibility`/`VISIBILITIES`/`V1Visibility` and\n`Guarantee`/`GUARANTEES`/`GuaranteeTolerant`/`V1Guarantee` no longer exist.\n\n**9. Status `steps[].intentHash` is REQUIRED** (`Bytes32`). The solver has always sent it; the\nschema now declares it. New golden fixture `intents.status:response:quote-filled-detail`.\n\n**10. Fixtures renamed:** `quotes.create:request:public-swap` → `…:request:swap`,\n`quotes.create:response:public-swap` → `…:response:swap`;\n`…:response:private-swap` is deleted.\n\n**11. The published OpenAPI document no longer carries `additionalProperties: {}`** on any\nresponse object. Semantically identical (JSON Schema is permissive by default) — it only stops\ndocumentation renderers drawing a `{key}: any` row. Request objects keep\n`additionalProperties: false`. Runtime parsing is unchanged: responses stay `looseObject`.\n\n## Migrating 0.7.0 -> 0.8.0\n\n**BREAKING under 0.x semver** (breaking bumps the minor while the major is 0). V1 quote requests\nmust now include `destination.recipient`; requests without it are rejected by\n`QuoteRequestSchema`. `V1QuoteRequest` reflects the same contract, so TypeScript consumers must\nprovide the field when constructing a quote request. This does not default to `funder` because\nthe funder and destination recipient can belong to different VMs.\n\n**`V1_SCHEMA_DIGEST` MOVES.** The OpenAPI request schema now lists `recipient` in\n`destination.required`. Every consumer running `assertNoSkew` must move to the new value in the\nsame rollout. The value is now\n`a61dfe727b15162f9097b421ca2f7660750e8cfad85ccf2d1c8dd8340207852a`; it was\n`3e13c5eeb8b054f3a48a22c7694de16b0fc11e1dbf6bc3c27e8c575100225b2a` on `0.7.0`.\n\n## Migrating 0.6.0 -> 0.7.0\n\n**BREAKING under 0.x semver** (breaking bumps the minor while the major is 0). Nothing on the\nwire that `0.6.0` accepted is rejected, and nothing `0.6.0` published is removed: two operations\nRETURN, one response field and one error code are ADDED. Three things still break, and one of\nthem is a live-behaviour change rather than a compile error — read all three before bumping.\n\n**`V1_SCHEMA_DIGEST` MOVES.** Both digest inputs changed (`errors/catalog.lock.json` gained one\ncode; `openapi/v1.json` gained two operations, two request schemas and one response field), so the\nvalue is now `3e13c5eeb8b054f3a48a22c7694de16b0fc11e1dbf6bc3c27e8c575100225b2a` — was\n`a6724fa4dd585e77aebe680655ac10fe5a2f4b70537930a0b4dee2612afb7c8e` on `0.6.0`. Every consumer\nrunning `assertNoSkew` must move to the new value **in the same rollout**; a mixed fleet fails\nthe check by design.\n\n**THE THREE BREAKING ITEMS FIRST.**\n\n**1. `LaneStandard` widens back to all four standards — a compile break for anyone keying on\nit.** `STANDARDS_BY_TARGET.quote` is `['erc-3009', 'permit2', 'permit3']` (`depositAddress` is\nunchanged), and `LaneStandard` is derived from the matrix, so it is now\n`'erc-3009' | 'permit2' | 'permit3' | 'erc-2612'` — the exact mirror of `0.6.0`'s narrowing.\n`V1_SUBMIT_SCHEMAS: Record<LaneStandard, …>` regains its `permit2`/`permit3` entries, and\n`V1_SUBMIT_SCHEMAS_BY_SERVICE.intents` has three lanes. **Your own `Record<LaneStandard, X>`,\nand every exhaustive `switch` over a `LaneStandard`, stops compiling until it gains two arms.**\nThat is the intended signal: the alternative is a dispatcher that meets `undefined` at runtime.\nA consumer that only indexes `V1_SUBMIT_SCHEMAS_BY_SERVICE['deposit-addresses']` is untouched.\n\n**2. A bare dependency bump WIDENS what a server ADVERTISES.** A router that derives its\n`/v1/tokens` `supports.quote` from `STANDARDS_BY_TARGET` advertises `permit2` and `permit3` the\nmoment this version is installed — before it can necessarily execute them. That is exactly the\nfalse promise `0.6.0` closed. Ship the bump in the same release as the lane implementation\n(quoted-salt dispatch, `execution.vault` publication, and the vault binding described under the\nadditive items), or gate discovery separately. This is the one item here that changes live\nbehaviour with no code change on your side.\n\n**3. Consumer-side, but read it: the lock gained a 400.** `V1ProblemSchema` cross-checks a KNOWN\ncode's `status`/`type` against the catalog. `vault-mismatch` (below) is now known, so a body\ncarrying that spelling with a contradicting status or type stops parsing where `0.6.0` tolerated\nit as \"a newer server\". An exhaustive `switch` over `V1ErrorCode` will not compile until it\nhandles it.\n\n**THE ADDITIVE ITEMS.**\n\n**Returned — `POST /v1/intents/submit/permit2` and `/permit3`.** This supersedes `0.6.0`'s\nbreaking item 4. The lanes can complete now because the two things that item named as missing\nexist: the router dispatches the QUOTED `route.salt` unchanged (so the intent it funds is the\nintent it quoted), and the quote response publishes the intent vault that salt produces\n(`execution.vault`, below), so a signer can name the vault-bound counterparty before signing.\nBoth operations, both `V1_ENDPOINTS` entries (`intents.submit.permit2`, `intents.submit.permit3`),\nboth golden fixtures, and the five schema exports `Permit2PermitSingleSchema`,\n`Permit2SubmitSchema`, `Permit3AllowanceSchema`, `Permit3PayloadSchema`, `Permit3SubmitSchema` are\nback. Path order in the document is `erc-3009`, `permit2`, `permit3` — the matrix order — and\nthe tokens fixture advertises the same three under `supports.quote`.\n\n**The bodies are NOT the `0.5.0` bodies.** A consumer skipping `0.6.0` (`0.5.0 -> 0.7.0`) sees\nSIX newly-required fields, and a `0.5.0` body is a 400 at these paths. This is the material the\nsolver's DTOs require and verify, which the `0.5.0` shapes omitted:\n\n```diff\n // POST /v1/intents/submit/permit2\n {\n+  \"chainId\": 8453,\n   \"target\": { \"quoteId\": \"quote:…\" },\n   \"permit2\": {\n     \"details\": { \"token\": \"0x…\", \"amount\": \"1043221\", \"expiration\": 1767225600, \"nonce\": 0 },\n-    \"spender\": \"<anything>\",\n+    \"spender\": \"<execution.vault of the quote>\",\n-    \"sigDeadline\": 1767225600\n+    \"sigDeadline\": \"1767225600\"\n   },\n   \"signature\": \"0x…\"\n }\n```\n\n```diff\n // POST /v1/intents/submit/permit3\n {\n   \"target\": { \"quoteId\": \"quote:…\" },\n   \"permit3\": {\n     \"owner\": \"0x…\",\n+    \"permitContract\": \"0x…\",\n     \"salt\": \"0x…\",\n     \"deadline\": 1767225600,\n+    \"timestamp\": 1767222000,\n+    \"merkleRoot\": \"0x…\",\n     \"permits\": [\n-      { \"chainId\": 8453, \"token\": \"0x…\", \"amount\": \"1043221\" }\n+      { \"chainId\": 8453, \"token\": \"0x…\", \"amount\": \"1043221\",\n+        \"account\": \"<execution.vault of the quote>\", \"modeOrExpiration\": 0 }\n     ]\n   },\n   \"signature\": \"0x…\"\n }\n```\n\n- **permit2 `chainId` (top-level, required)** is the EIP-712 domain chainId the signature was\n  produced under and the chain the permit executes on; the solver verifies the two agree. It\n  follows the C4 convention `erc-3009` and `erc-2612` already use.\n- **permit3 has NO top-level `chainId`**, deliberately: its EIP-712 domain is not the source\n  chain, and each leg names its own chain. A consumer that needs one chain id for the body takes\n  `permits[0].chainId`. It also carries no `leaves` and no `tokenKey` — the solver recomputes the\n  merkle tree from the legs, and `tokenKey` is `pad(token, 32)` (ERC-20 only) by definition.\n- **permit3 `permitContract`, `timestamp`, `merkleRoot`** are the signer's values, never\n  synthesized: the solver recomputes the root from the legs and rejects a mismatch.\n- **permit3 leg `account` and `modeOrExpiration`**: `account` is where the leg pushes funds\n  (mode `0`, immediate transfer) or grants the allowance (any other value, read as the allowance\n  expiration in Unix seconds). On a quote target it is always the vault.\n- **`nonce`, `expiration`, `timestamp` and `modeOrExpiration` are `Uint48`**, a new primitive\n  (with `UINT48_MAX`, `2^48 - 1`): the fields are uint48 on-chain and the ABI encoder truncates\n  rather than rejects, so the edge does. Expressed as bounds so the ceiling reaches the OpenAPI\n  document.\n- **permit2 `sigDeadline` is a decimal STRING (`UintString`), and `details.expiration` a\n  `Uint48`** — both carry their on-chain width instead of `UnixSeconds`. The Permit2 SDK's\n  `MaxAllowanceExpiration` (`2^48-1`) and `MaxSigDeadline` (`2^256-1`) are the standard \"no\n  expiry\" idiom many wallets sign, and a `<=2100` bound rejected a valid signature that would\n  have funded. Same narrow exception erc-3009's `validAfter`/`validBefore` carry; a NUMBER\n  `sigDeadline` is a 400 at `permit2.sigDeadline`. Every other deadline in the module\n  (`permit3.deadline`, erc-2612's) is still `UnixSeconds` and still rejects a milliseconds value.\n- **`Permit3PayloadSchema` stays a plain stripping `z.object`.** A `permit3.signature` sent in\n  the wrong place is dropped, so a reader has exactly one place to find the signature.\n\n**What the schema does NOT check, and the router does.** The body carries no vault, so the vault\nbinding cannot be a refinement here (`refineDepositAddressBinding` is a no-op on quote targets by\nconstruction). Before the signature pin the router asserts, per lane: the signed counterparty\n(`permit2.spender`, every `permits[].account`) equals the quote's `execution.vault` — compared\nCASE-INSENSITIVELY (`isSameEvmAddress`, exported here), since neither side is checksum-normalized\nand a naive `===` turns a checksummed vault against a lowercase signature into a spurious 400 —\nelse `vault-mismatch` (400); every permit3 leg `chainId` and the permit2 `chainId` equal the quote's\nsource chain; the token equals the quote's source token and the amount is at least the reward\namount for it; `permit2.details.expiration`, `permit2.sigDeadline`, `permit3.deadline` and a\nnon-zero `modeOrExpiration` are all more than 60 seconds in the future (a stale authorisation is a\n400, not a reverting funding batch). A green parse is not a green submit.\n\n**Added — `execution.vault` on every quote object (optional, nullable, `AnyAddress`).** The\nintent vault for THIS quote: the CREATE2 address the source-chain Portal funds the intent\nthrough, derived from the quoted intent (route.salt included), so it changes whenever the salt\ndoes. It is the value to sign as erc-3009 `authorization.to`, permit2 `spender` and every permit3\nleg `account`. **Absent means the producer predates the field; `null` means the producer could\nnot derive it** — today that is any non-EVM source (an SVM vault is a PDA and is not published).\n`AnyAddress` rather than `EvmAddress` because the same envelope carries SVM funding transactions\nand a future SVM producer must be able to publish the PDA here without a shape break; as always,\nnever infer a VM from the branch that matched. Each ranked `quotes[]` entry carries its own. The\nzod-free `V1Execution` alias gains `vault?: string | null`, and the parity spec pins the optional\nmember explicitly (an optional key is the one drift the mutual-assignability gate cannot see\nthrough a `looseObject`'s index signature).\n\n**Added — `vault-mismatch` (400): the signed counterparty is not the quote's intent vault.** The\nquote-target twin of `deposit-address-mismatch`, which is the wrong NAME on a quote target (there\nis no deposit address) — and `invalid-parameter` says nothing a caller can act on. `audience:\n'write'` — like the twin it needs a signed counterparty, so only a submit can emit it — and\n`legacyCodes: []` (no legacy service ever compared against a vault). A router's\n`detail` names the field (`permit2.spender`, `permit3.permits[1].account`, `authorization.to`),\nnever the signed address. Branch on `code`: it shares 400 with `invalid-request`.\n\n## Migrating 0.5.0 -> 0.6.0\n\n**BREAKING under 0.x semver** (breaking bumps the minor while the major is 0). Five items REJECT\na request `0.5.0` accepted or remove something `0.5.0` published; four are additive. Every\nbreaking item is listed here — if you send anything named below, read its entry before bumping.\n\n**`V1_SCHEMA_DIGEST` MOVES.** Both digest inputs changed (`errors/catalog.lock.json` gained one\ncode; `openapi/v1.json` lost two operations, gained two parameters and several descriptions), so\nthe value is now `a6724fa4dd585e77aebe680655ac10fe5a2f4b70537930a0b4dee2612afb7c8e` — was\n`1d8e88e957795b23e1317dc1e3783fd64bf79b756e3f28bd40e02b047542d790` on `0.4.0`, `0.4.1` and\n`0.5.0`. Every consumer running `assertNoSkew` must move to the new value **in the same\nrollout**. Unlike `0.5.0`, this time the skew check DOES see the difference, so a mixed fleet\nfails it by design rather than silently validating two ways.\n\n**THE FIVE BREAKING ITEMS FIRST.**\n\n**1. `slippage` now rejects `0` and anything below `0.0001`, and the rejection is named.**\n\n```ts\n// 0.5.0: parses (and then fails downstream). 0.6.0: 400, code slippage-out-of-bounds, path ['slippage'].\n{ ..., slippage: 0 }\n{ ..., slippage: 0.00005 }\n```\n\nThe range is `0.0001`-`1` (`SLIPPAGE_MIN`/`SLIPPAGE_MAX`, both exported), a DECIMAL FRACTION of\nthe destination amount: `0.005` is 0.5%. No solver can express a tolerance below one basis\npoint, so a `0` could only ever be rejected downstream, silently clamped, or silently replaced\nby a default; refusing it at the edge with a named code is the honest one. Zero tolerance is\nmeaningless on a swap route and ignored on a non-swap route, so nothing is lost.\n\n**The code changes for EVERY out-of-range value, not only the new floor.** `0.5.0` enforced the\nbound with a built-in `.min()/.max()`, which zod reports as `too_small`/`too_big` — and\n`v1ErrorCodeFromIssues` maps only a `custom` issue carrying `v1IssueParams`, so the catalog's\n`slippage-out-of-bounds` was promised and unreachable: `50` rendered as the generic\n`invalid-request` with `legacyCode: eco-quotes:1003`. It now renders as\n`slippage-out-of-bounds` (status 400 unchanged, `detail` text unchanged, no `legacyCode`\nbecause that code has none). An integrator branching on `code === 'invalid-request'` for a\nbad slippage, or reading `legacyCode` there, sees the change. The catalog TITLE names the\nfloor now; code, status and `legacyCodes` are untouched.\n\nThe published document also carries the units for the first time: both `slippage` fields have a\n`description`, and the request field keeps `minimum`/`maximum` (via `.meta()`, since the bound\nitself lives in a refinement that `z.toJSONSchema` drops). The response `slippage` is documented\nas the tolerance ACTUALLY bound into `destination.minAmountOut` — when a request omits\n`slippage`, that is the default the solver applied, not the omission.\n\n**2. A zero `amount` is rejected on the quote request.**\n\n```ts\n// 0.5.0: parses, reaches a solver, comes back as a 502. 0.6.0: 400, path ['source','amount'].\n{ ..., source: { chainId: 8453, token: '0x…', amount: '0' } }\n```\n\n`source.amount` and `destination.amount` are `PositiveUintString` (new primitive: `UintString`\nwith `'0'` excluded, message `must be greater than 0`). Every other `UintString` field is\nunchanged — a zero `value` on a destination call or a zero fee is still legal. The bound reaches\nthe OpenAPI document as a `description` only; a string has no `minimum`.\n\n**3. `options.maxCallDataSize` is gone.**\n\n```ts\n// 0.5.0: parses. 0.6.0: 400, unrecognized_keys at path ['options'].\n{ ..., options: { maxCallDataSize: 1000 } }\n```\n\nIt was published with no description and read by no service, so a caller sending it was handed\na 200 for a bound nobody enforced. The strict `options` object now names the key in a 400, the\nsame disposition `allowHighSlippage` has had since `0.3.0`. The zod-free `V1QuoteRequest` alias\ndrops the member too. A caller that needs a calldata cap needs one that is defined and enforced,\nwhich is a different change.\n\n**4. `POST /v1/intents/submit/permit2` and `/permit3` are WITHDRAWN.** (Superseded by `0.7.0`,\nwhich returns both lanes with the fields named below — see that section.)\n\nNeither lane can complete, and this is why. The signed Permit2 `spender` and every Permit3 leg\n`account` must be the intent VAULT (`Portal.fundFor` pulls the funds through\n`IPermit.transferFrom(funder, vault)`), and the vault is derived from the route salt the router\ndispatches — a value the signer cannot know before signing until quoted-salt dispatch and vault\nbinding exist. On top of that the published bodies omitted material the solver requires (permit2\n`chainId`; permit3 `permitContract`, `timestamp`, `merkleRoot`, per-leg `account` /\n`modeOrExpiration`), so the first refusal was a 401 on every request. Advertising a lane whose\nevery body ends in a 4xx is a false promise. The lanes return as a follow-on once quoted-salt\ndispatch and vault binding land; `erc-3009` is the quote-target intents standard until then.\n\nWhat moved, concretely:\n\n- `STANDARDS_BY_TARGET.quote` is `['erc-3009']`. `depositAddress` is unchanged.\n- The two registry entries, the two operations in `openapi/v1.json`, and the two golden fixtures\n  are gone (11 endpoints over 10 paths; 17 fixtures). A router that dispatches from\n  `V1_SUBMIT_SCHEMAS_BY_SERVICE.intents` answers `invalid-parameter` on those routes by\n  construction.\n- **Five exports are deleted:** `Permit3AllowanceSchema`, `Permit3PayloadSchema`,\n  `Permit3SubmitSchema`, `Permit2PermitSingleSchema`, `Permit2SubmitSchema`. No endpoint accepts\n  those bodies, so there is nothing for them to validate.\n- **`V1_SUBMIT_SCHEMAS` is keyed by the new `LaneStandard` type** (`'erc-3009' | 'erc-2612'` —\n  the standards that have a lane), not by `SubmitStandard`. `V1_SUBMIT_SCHEMAS[standard]` with\n  a `SubmitStandard`-typed index no longer compiles; narrow to `LaneStandard` first. That is the\n  intended signal — the alternative was an `undefined` a dispatcher trips over at runtime.\n- **`SUBMIT_STANDARDS` and `SubmitStandard` KEEP all four spellings.** That enum is also the\n  discovery vocabulary a token advertises under `supports`, and narrowing it would make a\n  consumer hard-fail on a token list from a server still spelling `permit3`. The vocabulary is\n  what a token MAY advertise; the matrix is what has a lane. The tokens fixture advertises\n  `quote: ['erc-3009']`.\n\n**5. Consumer-side only, but read it: the lock gained a 502.** `V1ProblemSchema` cross-checks a\nKNOWN code's `status`/`type` against the catalog. `solver-error` (below) is now known, so a body\ncarrying that spelling with a contradicting status or type stops parsing where `0.5.0` tolerated\nit as \"a newer server\". An exhaustive `switch` over `V1ErrorCode` will not compile until it\nhandles it.\n\n**THE FOUR ADDITIVE ITEMS.**\n\n**Added — `solver-error` (502): an upstream solver rejected or failed the quote request.**\n`solver-timeout` was the only 502, so a router had to label a solver answering 400 in six\nmilliseconds with a title that says \"timed out\". `solver-error` is the code for every upstream\nfailure that is NOT a deadline expiry — a solver 4xx/5xx, a network error, an unparseable body.\nIt is 502 rather than 4xx/422 on purpose: the gateway built the RFQ, so a solver rejection is a\ngateway/contract fault, never the caller's, and a 422 mapping would hide a contract bug as \"no\nroute\". `legacyCodes` is EMPTY by construction: `eco-quotes:1025` (Failed) is the ref that would\nbelong here, but it was published on `solver-timeout` and the lock is append-only, so it stays\nthere. Branch on `code`, not on `status`, to tell the two 502s apart.\n\n**Added — `?chainId=` on `GET /v1/chains` and `GET /v1/tokens`.** OPTIONAL on both (the\nunfiltered document is unchanged and stays legal), a single value only. A malformed value —\n`abc`, `0`, `-1`, `1.5`, or a repeated `?chainId=1&chainId=8453` — is a 400 at the field; a\nsyntactically valid chain id that matches nothing is a 200 with `chains: []` /\n`tokens: [], nextCursor: null`, never a 404. New exports: `CHAINS_LIST_QUERY_SHAPE` /\n`ChainsListQuerySchema`, `TOKENS_LIST_QUERY_SHAPE` / `TokensListQuerySchema`, and `ChainIdParam`\n(the coercing query-string twin of the body `ChainId`, which all three `chainId` query params —\nthese two and the deposit-address lookup's — now wrap, so the accepted set cannot differ between\nendpoints publishing the same parameter name). Query-side only: never coerce a chain id in a\nJSON body.\n\n**Added — `renderIssuesAsProblemParts(issues, opts?) -> { code, detail?, errors? }`, THE one\nsanctioned path from a `ZodError` to a problem body.** Two services rendered the same validation\nfailure with a cap of 4 and a cap of 10, a `(+N more issues)` suffix and an `N issues, first M:`\nprefix, a bare root message and a `(root)` placeholder, and only one of them emitted `errors[]`.\nThis function is the single set of conventions: cap `MAX_DETAIL_ISSUES` (8, now exported) for\nboth `detail` and `errors`; overflow is ONE trailing `(+N more issues)`; a root-level issue is\nits bare message; `errors` carries bare dotted fields and is omitted when nothing survives.\nAbsent keys are absent, so the result spreads straight into `problem(code, rest)` or your own\nbuilder. `problemFromZodError` is built on it and a test pins that the two produce byte-identical\nbodies. A service with its own problem type should route every `ZodError` through here and\ndelete its local cap and overflow constants.\n\n**Added — execution detail on a status entry.** `StatusEntrySchema` and `statusEntrySchemaFor`\ngain three OPTIONAL members: `sourceTx` and `destinationTx` as\n`{ chainId, txHash, token, amount }`, and `steps[]` as\n`{ type: 'SWAP' | 'BRIDGE', status, from, to, transactions: { created?, fulfilled?, refunded? } }`\nwith `{ token, amount, chainId }` legs and `{ chainId, txHash }` transaction refs. The shape\nmirrors the solver's step facts verbatim; the step `type` is the producer's vocabulary (not the\nquote-response `StepKind`) and the step `status` is the producer's raw per-step state beneath the\nC1 entry-level vocabulary, deliberately unmapped. **Absent means unknown; `null` is rejected** —\na null would read as \"known to be none\" on a lane whose upstream simply has no token/amount.\nToday the quote-status lane can populate them; the general intent-status lane omits them.\n`chainId` is a JSON number (the solver spells it as a string; the producer converts), amounts\nare uint strings, `token` is a bare string because the native asset may be a sentinel. New\nschema exports `StatusTxRefSchema`, `StatusTokenAmountSchema`, `StatusTxDetailSchema`,\n`StatusStepSchema`, `StatusStepType` / `STATUS_STEP_TYPES`; new zod-free aliases `V1StatusTxRef`,\n`V1StatusTokenAmount`, `V1StatusTxDetail`, `V1StatusStep`, `V1StatusStepType`.\n\n## Migrating 0.4.1 -> 0.5.0\n\n**BREAKING under 0.x semver** (breaking bumps the minor while the major is 0): this release\nREJECTS a request body `0.4.1` accepted. Nothing else moved — no code, status, `legacyCodes`\nmapping, or response shape changed.\n\n**`V1_SCHEMA_DIGEST` DOES NOT MOVE, and that is the caveat to read before rolling out.** The new\nrule is a `superRefine`, and `z.toJSONSchema` drops refinements, so neither digest input changed:\n`openapi/v1.json` is byte-identical and `assertNoSkew` cannot see the difference. A fleet running\n`0.4.1` and `0.5.0` side by side therefore passes the skew check while VALIDATING DIFFERENTLY —\nthe same body is a 400 on one instance and a 200 on another. Roll every consumer together, or\naccept that inconsistency knowingly.\n\n**Rejected — a `funder` that cannot share a chain with `source.token`.**\n\n```ts\n// 0.4.1: parses. 0.5.0: 400, path ['funder'].\n{ source: { chainId: 1399811149, token: '<a Solana mint>' }, funder: '0x3333…3333' }\n```\n\nBoth fields live on the SOURCE chain, so an EVM funder beside a Solana source token describes no\nchain that exists. It used to parse, get quoted, and then fail wherever a service classified the\nfunder against the source VM — and a service that read a malformed funder as ITS OWN material\nanswered `500 internal-error` for a field the caller sent.\n\n**What this rule deliberately does NOT do: bind `funder` to `source.chainId`.** That needs a\nchain-ID-to-VM table, and this package holds none by design — `ChainId` is any positive integer,\nand `ADDRESS_BY_CHAIN_TYPE` exists for the caller that already knows the chain type. A table here\nwould make every published version an allow-list of chains: a newly launched SVM chain would be\nmisclassified by every consumer still on an older pin, and its valid base58 funder rejected, so\nthis package would have to be re-released and rolled out before a chain could launch. Comparing\ntwo addresses from the same request needs no table and cannot go stale.\n\nSo the check is a NECESSARY condition, not a sufficient one, in two specific ways:\n\n- **Two EVM addresses agree with each other whatever `chainId` says**, including a Solana chain id.\n  A green parse is not evidence the funder is right for the chain.\n- **SVM and TVM are not separated.** A Tron base58check address also satisfies `SvmAddress`'s\n  32-44 character range (see the `AnyAddress` docblock), so shape cannot decide between them and\n  the rule lets that pair through rather than guessing.\n\nA service that knows the chain's VM must still check each address against it. Two new exports help:\n`addressFamilies(value)` returns every family a value is consistent with, and\n`addressFamiliesCanAgree(a, b)` is the pairwise predicate the refinement uses.\n\n## Migrating 0.4.0 -> 0.4.1\n\nPurely additive; no schema, wire, or digest change. `V1_SCHEMA_DIGEST` is UNCHANGED, so this is\nnot a coordinated-rollout release — a fleet may run 0.4.0 and 0.4.1 side by side.\n\n**Added — the two conformance skip reasons are exported constants.**\n`SIDE_EFFECT_SKIP_REASON` and `DRAFT_SKIP_REASON` are now named exports of the `./testing`\nsubpath. They were previously inline literals in this package's own spec, which meant a consumer\npinning them had to copy the strings and had no way to notice a rewording — the published tarball\nships `dist/`, never the sources those literals lived in. Import them instead of copying:\n\n```ts\nimport { DRAFT_SKIP_REASON, SIDE_EFFECT_SKIP_REASON } from '@eco-foundation/api-schemas/testing';\n```\n\nThis is also the first release cut from `eco/eco-api-schemas`, the package's own repository. It\npreviously shipped from a pnpm workspace inside `eco-incorp/router`; nothing about the published\nartifact's contents or layout changed with the move.\n\n## Migrating 0.3.1 -> 0.4.0\n\n`0.3.1` was never published, so **`0.4.0` is the upgrade from `0.3.0`** and carries `0.3.1`'s\nchange as well. It is a BREAKING release under 0.x semver (breaking bumps the minor while the\nmajor is 0), and it carries ONE breaking change plus two additive ones. The break is scoped to\nconsumers that read the **SVM** branch of a quote's funding transaction; EVM quotes are\nbyte-identical to `0.3.0`. Nothing here rejects a request body `0.3.0` accepted, and no existing\ncode, status, or `legacyCodes` mapping moved.\n\n**`V1_SCHEMA_DIGEST` MOVES.** Both digest inputs changed (`errors/catalog.lock.json` gained four\ncodes, and `openapi/v1.json` was regenerated for both the instruction list and the new response\nmember), so the value is now\n`1d8e88e957795b23e1317dc1e3783fd64bf79b756e3f28bd40e02b047542d790` — was\n`3d41b4893b54e77e9ea56c24af1d7a1e9de0685ee911e497834dcd746e72c1f6` on `0.3.0`/`0.3.1`. Every\nconsumer running `assertNoSkew` must move to the new value **in the same rollout**: the check\ncompares services against each other, so a fleet running two versions fails it by design.\n\n**THE BREAKING HALF FIRST (PAR-576), then the two additive ones (PAR-601, PAR-605).**\n\n**The SVM funding transaction is now an ORDERED LIST OF INSTRUCTIONS, not a serialized\ntransaction.** `SvmTransactionSchema` dropped `serializedTransaction` and gained `feePayer`\nand `instructions`:\n\n```diff\n-{ \"kind\": \"svm\", \"chainId\": 1399811149, \"serializedTransaction\": \"<base64 tx>\" }\n+{\n+  \"kind\": \"svm\",\n+  \"chainId\": 1399811149,\n+  \"feePayer\": \"<base58 pubkey>\",\n+  \"instructions\": [\n+    {\n+      \"programId\": \"<base58 pubkey>\",\n+      \"accounts\": [{ \"pubkey\": \"<base58>\", \"isSigner\": true, \"isWritable\": true }],\n+      \"data\": \"<base64: 8-byte Anchor discriminator + Borsh args>\"\n+    }\n+  ]\n+}\n```\n\n`serializedTransaction` is not deprecated-but-accepted; the key is gone and a body carrying\nit fails `QuoteResponseSchema`. That is deliberate — response schemas are `looseObject`, so\nleaving the old key valid would let a consumer keep reading a field the server no longer\nfills and get `undefined` at signing time instead of a named rejection.\n\n**Why the break, since `0.3.1` never shipped a working SVM quote:** a serialized Solana\ntransaction embeds a recent blockhash, valid for roughly 150 slots — 60 to 90 seconds. Every\nrealistic caller flow (fetch the quote, render it, let a human review it, sign, submit) is\nlonger than that, so the transaction was already dead when the caller signed it, the failure\nsurfaced as an opaque `BlockhashNotFound`, and the schema carried no field with which to\nrefresh it. The old shape was undeliverable rather than merely awkward. Instructions have no\nexpiry: the caller fetches its own blockhash at signing time, which is how every Solana\nwallet already works.\n\n**What the caller now owns.** In order:\n\n1. Fetch a recent blockhash (or use a durable nonce).\n2. Compile `instructions` **in the given order** into a legacy or v0 message, with `feePayer`\n   as the fee payer.\n3. Sign with every key marked `isSigner` — `feePayer` is always one of them.\n4. Choose its own compute-unit limit and priority fee. None is prescribed.\n\n**Two contracts that are load-bearing, and that no schema can check for you:**\n\n- **`instructions[].accounts` is POSITIONAL.** Solana resolves an instruction's accounts by\n  INDEX. Pass the array through verbatim — do not sort it, deduplicate it, drop an account\n  that also appears in another instruction, or regroup signers and writables. A permuted list\n  is a different instruction that still validates, and it fails on-chain with an unhelpful\n  message (a permuted Eco Portal `fund` reports `InvalidVault`, `InvalidAta` or\n  `InvalidTokenTransferAccounts` depending on which pair swapped). The schema does not know\n  which program `programId` is, so it cannot police this; it validates each entry's shape and\n  the PRESENCE of both privilege flags, and nothing more.\n- **`instructions` is one instruction in practice.** Since 0.9.0 the router emits `Portal.fund`\n  alone on Solana (the route preimage stays with the quoting solver; there is no `publish`), so\n  a funding transaction fits one Solana transaction. The array stays ORDERED and non-empty so a\n  producer that legitimately needs a companion instruction can add one without a wire change;\n  compile them in the given order.\n\n**No address-lookup-table references are emitted.** An ALT must already exist on-chain and\neco-router has no Solana RPC with which to create or read one, so every account is inline and\nthe message compiles as legacy. Bring your own ALT if you want a v0 message; the account metas\nare unaffected by that choice.\n\n**`isSigner` and `isWritable` are REQUIRED booleans** on every account meta, never optional and\nnever defaulted. Both directions of a wrong value are a real failure — a missing `isWritable`\nmakes the program's write revert, a missing `isSigner` makes Anchor's `Signer` constraint reject\nthe instruction — so absence is a 400 rather than a guess.\n\n**New, additive:** the `Base64Bytes` primitive (standard padded base64; URL-safe, unpadded, and\nwhitespace-bearing values are rejected, because Node's decoder silently accepts all three and\nstrict decoders do not), plus the `SvmAccountMetaSchema` / `SvmInstructionSchema` schemas and the\nzod-free `V1SvmAccountMeta` / `V1SvmInstruction` aliases.\n\n**Unchanged:** the EVM branch, every request schema, and the error catalog — it gained NO new\ncodes from this change.\n\n**TVM STAYS UNREPRESENTABLE, AND THAT IS NOW A DECISION RATHER THAN AN OPEN QUESTION.** Tron is\nOUT OF SCOPE for `/v1` funding. `FundingTransactionSchema` has no `tvm` member, a `kind: \"tvm\"`\ntransaction fails `QuoteResponseSchema`, and eco-router answers `chain-not-supported` (422) for a\nTron-source funding quote. Do not read the SVM lane as a precedent that a `tvm` branch is queued\nbehind it: adding one would be a breaking wire change with its own migration note, and nothing\nhere commits `/v1` to that surface.\n\n**Added — `./package.json` is an exported subpath.**\n`require('@eco-foundation/api-schemas/package.json')` previously threw\n`ERR_PACKAGE_PATH_NOT_EXPORTED`, which broke tooling that reads a dependency's manifest for\nits version. Nothing else changes; it is purely additive. (`prepack` now also rebuilds\n`dist/` on a manual `npm pack`/`npm publish`, which affects publishing rather than\nconsuming.)\n\n**Added — the `errors` problem extension (per-field caller faults).**\n\n```json\n{\n  \"type\": \"https://.../invalid-request\",\n  \"title\": \"Invalid request\",\n  \"status\": 400,\n  \"code\": \"invalid-request\",\n  \"detail\": \"source.chainId: must be a supported chain id\",\n  \"errors\": [{ \"field\": \"source.chainId\", \"detail\": \"must be a supported chain id\" }]\n}\n```\n\n`errors` is **OPTIONAL**: an `invalid-request` for a body that is not JSON at all has no\nfield to name, so absence is legal and means exactly that. `field` names the offending\ninput in YOUR terms — the path into what you sent, with **no `body.`/`query.` prefix**:\n`source.chainId`, `source.funder`, `limit`. `detail` obeys the same free-text policy as the\nproblem's own `detail`.\n\nBecause there is no prefix, `field` alone does not say whether the value came from the body\nor the query string. Every /v1 endpoint takes its parameters in exactly one of the two, so\n**key on the route plus `field`**, not on `field` alone.\n\n**`errors` is NOT `solverErrors`.** They sit adjacent and answer different questions:\n`errors` is your own fault (a field you sent, and naming it is how you fix it);\n`solverErrors` is a downstream solver's failure, which you did not cause and usually\ncannot fix. A body never needs both to explain one failure. The name `errors` is the\nde-facto RFC 9457 validation extension (Spring `ProblemDetail`, ASP.NET\n`ValidationProblemDetails`), so it is probably already in your SDK.\n\n`problemFromZodError` populates it from the issues it already renders into `detail`, so\nyou get the machine-readable form for free — bounded to 8 entries, and an issue with no\npath is omitted rather than given a placeholder field.\n\n**Added — `chains`, REQUIRED on the deposit-address create response (PAR-571).**\n\n```json\n{\n  \"id\": \"deposit-address:0x…\",\n  \"chains\": [\n    { \"chainId\": 8453, \"source\": true, \"registration\": \"registered\" },\n    { \"chainId\": 137, \"source\": false, \"registration\": \"registered\" }\n  ]\n}\n```\n\nFour identifiers, two pairs, and the members of a pair are one word apart — pair them\ncarefully, because the wrong pairing still compiles.\n**`DepositAddressChainRegistrationSchema`** is the ENUM and\n**`DepositAddressChainRegistration`** its inferred type;\n**`DepositAddressChainStatusSchema`** is the OBJECT that `chains[]` holds and\n**`DepositAddressChainStatus`** its inferred type. The `Schema` suffix is what distinguishes\nschema from type — the bare name is always the type.\n\n**REQUIRED on the create response, and absent from the shared record.**\n`DepositAddressCreateResponseSchema` is now `DepositAddressSchema.extend({ chains })`\nrather than a bare alias. If you read a create response, `chains` is always there; if you\nread a lookup page, it is never there. That is deliberate — an optional member on the\nshared record would make one key mean \"bug\" on one lane and \"correct\" on the other, with\nnothing in the type to distinguish them. **Migration:** a server build that returns 201\nwithout `chains` now fails its own response schema.\n\n`.min(1)`: the source chain is always attempted, so an empty array could only mean the\nproducer lost the outcome — and an empty `chains` reads as \"no chain is live\", the\nopposite of what a 201 means.\n\n**Two constraints are enforced beyond the shape:** exactly one entry has `source: true`,\nand no `chainId` repeats. `source` is what tells you which chain the top-level\n`depositAddress` is definitely correct for, so zero or two source entries would be a\nsilently wrong answer about where funds may go. Errors name the field and carry the count\n(`chains must contain exactly one source entry, found 2`); a duplicate is reported at the\noffending index.\n\nThese live in a `superRefine`, which means **they do not appear in `openapi/v1.json`** —\n`z.toJSONSchema` drops refinements. Validate against the zod schema if you need them\nenforced; a client generated from the OpenAPI document alone will accept a body the zod\nschema rejects.\n\n**What `.min(1)` does NOT give you:** it rejects an empty array, not an incomplete one. A\nschema cannot know which chains should be present. Completeness is a producer guarantee —\ndeposit-addresses builds the array from the full attempted set — not something validated\nhere.\n\nTwo things to read correctly:\n\n- **`registration` is binary today.** The enum exists so `'pending'` can be added\n  additively if a retry lane is ever built; there is no such lane, so do not look for a\n  third state.\n- **`registration: \"registered\"` means the chain-state ROW EXISTS.** That row is what the\n  polling services rebuild their watch set from at boot. It does NOT promise the\n  in-process publish succeeded, so it can **lead the live process by one restart**. Read\n  it as \"known, and picked up no later than the next boot\" — never \"being watched right\n  now\". It is also **not** `isDeployed`, which is CREATE2 deployment of the address\n  contract: `isDeployed: false` does not mean \"do not send funds here\".\n\nNew zod-free aliases: `V1DepositAddressChainStatus` and `V1DepositAddressCreateResponse`.\n\n**Added — four error codes for the transport statuses `/v1` could not answer (PAR-601).**\n\n| Code                     | Status | Reached by                                                   |\n| ------------------------ | ------ | ------------------------------------------------------------ |\n| `endpoint-not-found`     | 404    | a typo'd path — no `/v1` endpoint at that path               |\n| `method-not-allowed`     | 405    | a real path, wrong HTTP method                               |\n| `request-too-large`      | 413    | body bytes over the limit, or too many urlencoded parameters |\n| `unsupported-media-type` | 415    | an unsupported media type, charset, or content encoding      |\n\nAll four are `audience: 'all'` and carry no `legacyCodes`. Before `0.4.0` these four statuses\nhad no catalog code at all, so a `/v1` response at any of them fell through to eco-router's\nlegacy envelope — a partner SDK keying on `type`/`code` saw neither.\n\n**The one newly-possible rejection, and it is consumer-side.** `V1ProblemSchema` cross-checks a\nKNOWN code's `status`/`type` against the catalog and ignores codes it does not know. These four\nare now known, so a problem body carrying one of them with a CONTRADICTING status or type stops\nparsing where `0.3.0` tolerated it as \"a newer server\". If you already emit any of these four\nspellings, confirm the status and `type` match the table above before upgrading.\n\n**`endpoint-not-found` is NOT `token-not-found`.** Both are 404. A consumer branching on status\nalone will conflate \"that path does not exist\" with \"that token is unknown on that chain\" —\nbranch on `code`.\n\n**Exhaustive `switch` over `V1ErrorCode` will not compile until you handle the four.** That is\nthe intended signal, not a break to work around.\n\n**Added — `/v1/chains` may advertise the deployment's effective page bounds (PAR-605).**\n\n```json\n{\n  \"chains\": [{ \"chainId\": 8453, \"...\": \"...\" }],\n  \"limits\": { \"paging\": { \"maxLimit\": 25, \"defaultLimit\": 10 } }\n}\n```\n\n`limits` is **OPTIONAL**, and **absence has a documented meaning: the published `PagingFields`\nbounds apply** — cap `STATUS_PAGE_MAX_LIMIT` (50), default `STATUS_PAGE_DEFAULT_LIMIT` (20),\nwhich is exactly the `0.3.0` contract. So a server that does not populate it stays correct and\na consumer needs no new branch. When `limits` IS present, `paging` is required inside it:\n`limits: {}` is rejected rather than read as \"bounds advertised, none given\".\n\nAn operator may only NARROW, so both numbers are capped at the canon values, and\n`defaultLimit <= maxLimit` is enforced — a deployment cannot advertise a first page it would\nreject on request.\n\nRead it if you choose page sizes programmatically. The 400 that names the bound is unchanged;\nthis exists so the bound is discoverable in one request rather than one rejection.\n\n**Scope — it is the bound of the service serving that document.** eco-router serves\n`/v1/chains` and `/v1/intents/status` from one config, so its answer covers both.\n`/v1/deposit-addresses/status` and the `/v1/deposit-addresses` lookup are the\ndeposit-addresses service's, paged from its own config; `DepositAddressLookupResponseSchema`\ndeliberately does not carry this member.\n\n**Carried over from the unpublished `0.3.1`: the `zod` peer is now `optional`.** The range is\nunchanged (`^4.3.0`). It only widens the set of installs that resolve cleanly — a consumer\nimporting only the zod-free entry points (`./v1/signature`, `./v1/types`) no longer gets a\npermanently wrong unmet-peer warning. `optional` suppresses the warning only when zod is\nABSENT: a consumer holding a zod outside `^4.3.0` still sees a version-mismatch warning.\n\n## Migrating 0.2.0 -> 0.3.0\n\n`0.3.0` is a BREAKING release under 0.x semver (breaking bumps the minor while the major\nis 0). It contains exactly ONE change, and it rejects request bodies `0.2.0` accepted.\n\n**Newly rejected — an unknown or misplaced key ANYWHERE in a quote request.**\n`QuoteRequestSchema` and every object nested inside it are now `strictObject`: the root,\n`source`, `destination`, each entry of `destination.calls[]`, and `options`. In `0.2.0` any\nkey the schema did not declare was silently STRIPPED and the request answered `200`. It is\nnow a 400 whose `unrecognized_keys` issue names the offending key and the path of the object\nit appeared in.\n\n**The break you are most likely to hit: a field you have been sending at the wrong nesting\nlevel.** It has been silently ignored the whole time, so nothing looked wrong, and on upgrade\nit starts returning 400. The known shapes of that mistake:\n\n| Sent as                     | Belongs at                 | What `0.2.0` did                                     |\n| --------------------------- | -------------------------- | ---------------------------------------------------- |\n| `source.funder`             | `funder`                   | dropped it; the request had no funder                |\n| `destination.slippage`      | `slippage`                 | dropped it; priced at the default tolerance          |\n| `visibility`                | `options.visibility`       | dropped it; a route you wanted private was published |\n| `options.dappId`            | `dappId`                   | dropped it; you lost attribution                     |\n| `options.allowHighSlippage` | nowhere (deleted in 0.2.0) | dropped it silently                                  |\n\n`source.funder` is not a hypothetical: spelling `funder` there is how a funder-vs-signer check\non the money path became a permanent no-op once before, and how two guards were later found\nreporting protection they did not provide — they read the nested path, the key was never\nthere, and `undefined === undefined` passes for every input. A strict root turns that into a\nnamed 400 at the edge instead.\n\n**Before you upgrade,** log the request bodies your client actually sends and diff their key\nsets against the schema. A field the server was ignoring is a field your integration was\nalready not getting; the 400 is the first time you find out.\n\n**Two behaviors worth knowing:**\n\n- An unrecognized key ABORTS the parse, so the cross-field diagnostics (the D7\n  `destination.calls` rules, the exact-out `amount` rules) do NOT also report on the same\n  response. Fix the key, re-send, and the rest appears. Pinned in a test.\n- RESPONSE schemas are untouched and stay `looseObject` at every level. Forward compatibility\n  runs the other way: a consumer must keep parsing fields a newer server adds. Also untouched:\n  the four submit BODY schemas and their signed value objects (`Permit3Payload` relies on\n  stripping a misplaced `permit3.signature`, so a reader has exactly one place to find the\n  signature), and the three querystring schemas (proxies and clients add query params, a\n  different risk profile from a JSON body).\n\nThe error catalog gained NO new codes — `invalid-parameter` and `invalid-request` already\ncover this. `V1_SCHEMA_DIGEST` changes, as it must: the published `openapi/v1.json` gains\n`additionalProperties: false` on all five request objects.\n\n## Migrating 0.1.0 -> 0.2.0\n\n`0.2.0` is a BREAKING release under 0.x semver (breaking bumps the minor while the major\nis 0). Three tightenings reject request bodies `0.1.0` accepted, and one packaging change\nalters how `zod` is resolved. Nothing here is a silent behavior change — every item below\nturns something that used to succeed into a named 400 or a failed install.\n\n**Install-time — `zod` is now a `peerDependency` (`^4.3.0`), not a dependency.** A consumer\nthat relied on the transitive copy must now declare `zod` itself. This is the fix for the\ntwo-zod-instance failure: the old exact `4.4.3` pin materialised a second nested zod for any\nconsumer not on that exact version, producing `TS2345` on `_zod.version.minor` and `tsc`\nOOMing at 4 GB with no message.\n\n**Newly rejected — an amount at or above 2^256.** Every field typed `UintString` (quote\n`source.amount`, `destination.amount`, fee/step amounts, `permit.value`, `permit.nonce`,\nerc-3009 `value`/`validAfter`/`validBefore`, `gasLimit`, ...) is now bounded at `2^256-1`.\n`0.1.0` validated a 200-digit value cleanly and let it revert or truncate on-chain. The\npublished OpenAPI carries the coarse `maxLength: 78`; the exact ceiling is enforced on every\nparse.\n\n**Newly rejected — an unknown key on `POST /v1/deposit-addresses`.** All three\n`kind` variants of `DepositAddressCreateRequestSchema` are `strictObject`. In `0.1.0` a\nmisspelled field, or a field belonging to a different `kind` (`destinationChainId` on the\nsame-chain `gateway` variant), was silently STRIPPED and answered with a `201` — a\nfunds-receiving address created with semantics the caller did not request. It is now a 400\nnaming the offending key. Read paths and the lookup query are unchanged.\n\n**Newly rejected — a redirected `permit.spender` on\n`POST /v1/deposit-addresses/submit/erc-2612`.** `permit.spender` must equal\n`target.depositAddress`, the same binding all three erc-3009 variants already enforced on\n`authorization.to`. A redirected spender was previously accepted here and then silently\nRE-ADDRESSED by the permit-transfer path.\n\n**Changed error rendering (not a rejection).** Both binding refinements now carry the\n`deposit-address-mismatch` catalog code as issue data, so a consumer rendering through the\nnew `problemFromZodError` gets that code and its 400 instead of the generic\n`invalid-request` — on the erc-3009 lane that is a code CHANGE for an already-rejected body.\nThe code's catalog `title` generalizes to \"The signed counterparty does not equal\ntarget.depositAddress\" (it named erc-3009 only); code, status and legacy refs are untouched.\n\n**No validation change, but worth knowing.** `AnyAddress` now tries `TvmAddress` before\n`SvmAddress`, so the `anyOf` branch ORDER in the published document differs. Every branch is\na plain string, so accepted values and parsed output are identical — and `AnyAddress` must\nnever be used to infer a VM either way (see its docblock). `V1_SCHEMA_DIGEST` changes, as it\nmust: it is the artifact identity, not the version string.\n\n**New, additive:** the zod-free `./v1/signature` subpath; `MAX_UINT256`; and\n`problemFromZodError` / `v1ErrorCodeFromIssues` / `v1IssueParams` / `V1_ISSUE_CODE_PARAM`.\n\n## Consumers\n\n| Consumer                             | Import                                                                                   | Zod requirement                        |\n| ------------------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------------- |\n| eco-router (serves /v1)              | `import { v1 } from '@eco-foundation/api-schemas'`                                       | own zod satisfying the peer range      |\n| deposit-addresses (native endpoints) | same, plus `assertMatchesV1Schema` from `./testing` in CI                                | own zod satisfying the peer range      |\n| solver-v2 (Zod 3 — must not upgrade) | `import type { V1QuoteResponse } from '@eco-foundation/api-schemas/v1/types'` + fixtures | ZERO zod at runtime and in the `.d.ts` |\n| any consumer needing `signatureHash` | `import { signatureHash } from '@eco-foundation/api-schemas/v1/signature'`               | NONE — that subpath is zod-free        |\n\n**Do you need `zod`? Only if you import a zod-bearing entry point.** Since `0.3.1` the peer is\ndeclared optional (`peerDependenciesMeta: { zod: { optional: true } }`), because for two of the\npublished entry points it is genuinely not needed:\n\n- **Needs `zod` (`^4.4.0`):** the bare package name `.`, `./testing`, and anything reached\n  through the `v1` namespace on either. These load schema modules, and their `.d.ts` names zod\n  types.\n- **Needs NO `zod`:** `./v1/signature` (runtime code importing `@noble/hashes` and nothing else)\n  and `./v1/types` (plain `type` aliases, erased at compile time). A consumer whose imports stay\n  inside these two installs only `@noble/hashes` — declaring zod would be dead weight.\n\nRead `optional` narrowly: it says zod **may be absent**, not that any zod version works. pnpm\nsuppresses the unmet-peer warning only when zod is MISSING (verified against pnpm 10.16); a\nconsumer that HAS a zod outside `^4.4.0` — solver-v2, on zod 3 — still sees\n`unmet peer zod@^4.4.0: found <version>`, since that is a version mismatch rather than a missing\npeer. Suppressing that one is the consumer's own call\n(`pnpm.peerDependencyRules.allo","readmeFilename":"README.md"}