Quick answer
Every transmission script in Code: Terraform needs the same order: get the transmitter, connect to Earth, then transmit a key/value pair. The first sensor uplink uses a descriptive key like current_temperature. Contract submissions follow the same pattern, except the key should be the current contract ID string and the value should be the answer your contract logic already computed.
The transmission sequence
For a contract submission, get the transmitter and connect to Earth after your contract logic has produced two real values in your script:
contract_id— the current contract’s ID string.answer— the result you calculated for that contract.
Then the transmission portion is:
transmitter = get_component("transmitter")
transmitter.connect("Earth")
transmitter.transmit(contract_id, answer)This is a transmission pattern, not a universal contract solution. The site deliberately does not invent a contract ID or answer.
The rules, as the in-game docs state them
The starter walkthrough shows the transmitter documentation on camera, and it settles every recurring question in one paragraph: the key is the contract ID, the value is the computed answer, the game validates the payload on arrival and either pays the credits with a success message or prints an incorrect-answer hint — and transmit() returns none in both cases, so success is observed through credits changing, not the return value. Every script that transmits must connect first, and the connection only lives for the current script run.
A recorded contract, end to end
One recorded session solved the alien-gene-sequences contract, which is a good example of the shape: Earth sends 50 known reference genome sequences, and the objective is to extract every sample not found in the reference set and transmit the result as a list.
The instructive part is the failure. The first submission came back with the game’s incorrect-answer hint, and the bug was in the answer-building loop, not the uplink: a word that was already in the result list was being appended again, so the transmitted list contained duplicates. The recorded fix was to check membership before adding. That is exactly why the compute-then-send split matters — when the answer is built in its own section, a rejection tells you to debug the algorithm, not the transmitter.
Separate computation from delivery
For harder contracts, compute the answer first and keep that result in a variable. Only after the answer is ready should you connect the transmitter and send it. This makes it much easier to distinguish a bad answer from an uplink mistake — the recorded gene-sequence session only found its bug after isolating the two halves.
Common mistakes
- Reusing a transmitter assumption from an earlier run without reconnecting — the connection does not survive between runs.
- Passing a contract object where the API wants the contract ID string. The recorded error is
I expected string for key. - Debugging the transmitter when the actual contract answer is wrong. There is no transmit-side error for a wrong answer; the only signal is the incorrect-answer hint and the credits not changing.
- Building the answer list without de-duplicating. See the recorded gene-sequence failure above.
Where the rewards go
Contract payments land as credits, which is what funds the rest of the opening game: the solar generator and battery, lab reagents, and further machines. The first contact uplink pays the first 1,000 credits and unlocks the shop; later Earth contracts like the gene-sequence example stack on top of it.
Worked contract examples
Two of the harder contracts are written up end to end on their own pages: the Orbital Relay Hack (a six-tumbler lock that reports each position’s state) and the Xenogenetics Survey (filtering a thousand samples against Earth’s reference set). Both follow the connect-then-transmit rule this page describes.
Evidence and version notes
The connect-first rule, string-key requirement, none-return behavior, validation-on-arrival wording, and the gene-sequence contract walkthrough are from recorded playthroughs (closed testing and public demo builds, September 2026). The Early Access build launched September 9, 2026 and adds more contract types; build 0.1.22 (September 13, 2026) expanded scripting support for component types, build versions and upcoming orders and fixed marker arguments — so if a contract script referencing order data failed on the launch build, re-run it after updating before rewriting the logic. This page publishes only what completed on camera, and your build’s contract text is the authority on IDs and answer formats. The component reference documents the transmitter row these scripts run on. Full changelog: patch notes.