Developers
Declare the system. One command does the rest.
Phyntec CLI deploys, links and records contract systems from one manifest, on any network, today. The SDK does the same from code. The engine's own commands arrive with general availability in 2027.
$ cat bond-system.yaml kind: System spec: system: { name: BondLifecycle } packages: - name: Terms - name: Schedule - name: Payments functions: "*" $ phyntec apply -f bond-system.yaml compiled 3 packages deployed BondLifecycle at 0x7A3f...c1e2 (deterministic address) linked Terms, Schedule, Payments recorded in project bond-pilot
Phyntec CLI
Stop writing deployment scripts.
Describe what you want in a manifest: a contract, a package, or a whole system of packages. Phyntec CLI compiles, deploys, links the pieces by name and records the result in your project. Same address on every network.
Ask for access- 01
Three manifest kinds
A contract, a package, or a system of packages. Dependencies are named, and their addresses are injected.
- 02
One command
Compile, deploy, link and record in a single apply. Rerun it and only what changed moves.
- 03
Your project keeps the record
Every deployment lands in your project on the platform with its ABIs, graph and history.
What ships
Open tooling. A platform that keeps the record.
Phyntec CLI and the SDK are open source. The platform keeps your projects, artefacts and deployments in one place, with the graphs, ABIs and history your auditors ask for. Proof status for the engine is published per contract family.
Modular by design
Systems built from packages.
A system is a set of packages behind one proxy, sharing one storage. Logic is split across packages, so the contract size limit disappears, and a single package can be replaced without redeploying the system.
- 01
Declared deployments
Three manifest kinds: a contract, a package, a system. Dependencies are referenced by name and their addresses injected.
- 02
No size limit
Logic lives in packages behind a proxy, so a system is never blocked by the 24KB limit of a single contract.
- 03
Upgrade one piece
Replace a package and keep the rest, with the shared storage intact.
- 04
Same address everywhere
Deterministic addresses by default, so a system lands on the same address on every network you deploy to.
The platform
Every artefact, every deployment, one record.
Sign in from the terminal, pick a project, and the platform keeps what you compiled and where it went. Only what changed is uploaded.
Ask for access- 01
Projects
Contracts, networks and deployments organised per project and per team.
- 02
Artefact sync
Change detection means only modified contracts are synced; a status view shows what is synced, modified or new.
- 03
Deployment tracking
Graphs of what links to what, ABIs, transaction history.
- 04
Networks and nodes
A registry of networks to search and switch between, a local node with mainnet forking, wallets generated on demand.
The SDK
The same manifests, from code.
Apply a manifest from TypeScript in a pipeline or a test. Typed results tell you what was deployed and where.
Ask for accessimport { apply } from "@phyntec/sdk"; const result = await apply({ manifest: "bond-system.yaml", network: "sepolia", }); console.log(result.system.address); // 0x7A3f...c1e2
The engine
Specification in. Schedule and messages out.
At general availability the engine joins the same command line: a term sheet becomes a specification you can read, the engine computes the event schedule and writes the ISO 20022 messages for each event. Every number comes from the engine, never from a model.
See the engine$ phyntec spec bond-2031.term.yaml wrote bond-2031.spec.json (fixed-rate bond, 12 events) $ phyntec schedule bond-2031.spec.json 2027-03-15 coupon EUR 2,250,000.00 2027-09-15 coupon EUR 2,250,000.00 2031-03-15 redemption EUR 100,000,000.00 $ phyntec messages bond-2031.spec.json --iso20022 out/ wrote 12 messages, 0 warnings $ phyntec check bond-2031.spec.json conformance: 148 passed, 0 failed
Per contract family
Each family arrives with its artefacts.
A family is released when its specification, implementation, conformance suite and proof status are all published. You can run the suite and the checker yourself.
- 01
Specification
The contract terms, the event model and the mapping to ISO 20022 messages, versioned.
- 02
Conformance suite
Reference cases with expected schedules and messages. Run it against any implementation.
- 03
Checker and proof scripts
The machine-checked proof that the implementation matches the specification, with the checker used to verify it, published with the family's proof status.
- 04
Trusted computing base note
What the proof covers and what it does not, named per family.