Developer Agreements for Businesses Building on Bitcoin

By Hank FasthoffSeptember 17, 2026

A business may hire a developer to connect a store to a payment server, build a wallet interface, or create internal software for approving transfers. Each project can combine newly written code with software the developer already uses and components maintained by other people. The agreement has to distinguish those materials and establish what the business can operate, modify, and maintain after the developer leaves.

The commercial questions begin with the intended result. A demonstration, a product ready for customer use, and a contribution submitted to a public project involve different obligations. Before development begins, you should identify the deliverables, the rights the business requires, and the decisions that depend on someone outside the engagement.

Defining the Deliverable

A statement of work sets the scope of a development engagement. For a payment integration, that scope might include generating invoices, recognizing completed payments, handling duplicate notifications, and providing information for refunds. A description such as “add bitcoin payments” leaves those functions and their completion standards unresolved.

The statement of work also addresses what accompanies the functioning software. Source code, which is the human readable form developers use to maintain a program, may require build instructions, configuration information, and documentation before another developer can use it effectively. You should identify those materials as deliverables and establish when the company receives them.

An engagement to contribute to a public project requires a different completion standard. Bitcoin Core's contribution guidelines place the decision to incorporate a proposed change with the project's merge maintainers and describe peer review timing as unpredictable. A funding agreement should distinguish preparing and submitting a contribution, responding to review, and obtaining its acceptance. Those milestones allocate the consequences of a decision the hired developer does not control.

Copyright Ownership and the Hiring Relationship

Under 17 U.S.C. § 201(a), copyright vests initially in the author or authors. For a qualifying work made for hire, § 201(b) treats the employer or commissioning party as the author. That party owns the copyright unless the parties agree otherwise in a written instrument signed by them. Whether software qualifies depends on the statutory requirements and the facts of its creation.

Section 101's definition of a work made for hire distinguishes an employee's creation within the scope of employment from certain specially commissioned works. The commissioned category requires a signed written agreement and a qualifying use within one of nine listed categories. Computer programs are not a separate category on that list, so a work for hire label alone cannot resolve ownership of commissioned software.

Employee status depends on the hiring relationship. The Copyright Office's guidance explains that the copyright analysis uses agency law and considers factors such as control, tools, duration, and the hiring relationship. Describing someone as a contractor or employee in the agreement does not conclusively settle that analysis.

For deliverables your business intends to own, you should obtain a written assignment covering the applicable copyrights, patent rights, and trade secret rights. The agreement should also address ownership of patent applications and resulting patents, the developer's cooperation in securing those rights, and any existing materials excluded from the assignment.

Under 17 U.S.C. § 204(a), a transfer of copyright ownership, other than by operation of law, requires a writing signed by the owner of the rights transferred or an authorized agent. Without the required signed writing, the intended contractual transfer of copyright ownership is ineffective. The agreement also needs to specify when the transfer takes effect, including whether it depends on payment and what use is permitted before that condition is met.

Hiring a development company introduces another ownership question. The company signing the agreement may rely on employees or subcontractors to create the code. Its ability to transfer the promised rights depends on the rights it acquires from those contributors, making contributor agreements and authority to grant the required rights part of the engagement review.

Existing Tools and Open Source Components

A developer may propose using a library written before the engagement, a commercial component, or software available under an open source license. The contract can identify those materials, specify what the developer retains, and provide the business with the license necessary for its intended use.

For a retained component, you should confirm that the license permits the business to operate the product, modify it, and engage another developer to maintain it. A business planning to sell or license the product also has to account for distribution and customer use. Any restriction on transferring the license can affect a future sale of the product or business.

BTCPay Server's MIT license permits use, modification, distribution, and sale of copies, subject to preservation of the copyright and permission notices in copies or substantial portions of the software. It also contains warranty and liability disclaimers. Those terms illustrate why permission to use an open source component and a paid developer's promises about implementing it require separate analysis.

You should require disclosure of the components and versions incorporated into the project, together with their licenses and required notices. The review can then address the particular combination and the business's intended deployment and distribution. The developer agreement should assign responsibility for identifying applicable obligations, delivering required materials, and obtaining approval before introducing a component with terms inconsistent with the agreed product model.

Public Contributions and Reuse

Some businesses want their commissioned code released publicly. Others intend to keep particular application code private while contributing improvements to an underlying project. The agreement should identify which materials may be published, who approves publication, and which license the business authorizes.

Bitcoin Core's contribution guidelines provide that contributors license their contributions under the MIT license unless a different license is specified in the identified copyright file or the contributed file. When the company owns the copyright, the developer must have authority to grant the applicable license. The development agreement should specify whether that authority covers defined contributions or requires approval before each submission.

The developer's right to reuse materials warrants a separate decision. A business may permit reuse of general tools while restricting reuse of its commissioned code, confidential information, or branding. Defining those permissions avoids treating every file delivered during the engagement as having the same ownership and reuse rules.

Access to Systems and Payment Functions

A developer's assignment may require access to repositories, hosting accounts, customer information, or systems that can initiate payments. Each type of access creates a different operational responsibility. You should establish who authorizes that access, its permitted purpose, and the conditions for changing or removing it.

For software that can affect company bitcoin, the agreement should address authority to change payment destinations, deploy changes to the live system, and participate in signing or recovery procedures. Technical personnel can identify the permissions the developer requires and the controls that restrict their use. Counsel can document the agreed authority, approval procedures, and consequences of unauthorized activity.

The parties can define security obligations by specifying who performs technical testing, who receives reports, which findings require correction before release, and who approves use of the software with live funds. Contract drafting translates those decisions into obligations; qualified technical personnel perform and assess the testing.

Confidentiality and Protected Disclosures

An open source product can coexist with confidential customer records, credentials, business plans, and unpublished development information. The confidentiality provisions should identify permitted use and disclosure, including access by approved subcontractors and use of external development tools. Publicly available code and information the developer may lawfully use require appropriate treatment in those provisions.

Federal trade secret protection depends on more than a confidentiality clause. 18 U.S.C. § 1839(3) requires reasonable measures to preserve secrecy and independent economic value arising from the information's secrecy and lack of ready ascertainability through proper means. Access restrictions, handling instructions, and return or deletion procedures can support those measures, depending on the circumstances.

Under 18 U.S.C. § 1833(b), employers must provide notice of immunity for specified protected disclosures in agreements governing trade secrets or other confidential information entered into or updated after May 11, 2016. For this requirement, employees include individual contractors and consultants. The statute permits compliance through a qualifying reference to a reporting policy supplied to the individual. An employer that omits the required notice cannot recover exemplary damages or attorney fees under the identified federal trade secret provisions against the individual who did not receive it.

Acceptance, Corrections, and Maintenance

Acceptance terms determine how the business evaluates delivery and when it must identify defects. The agreement can specify the test environment, review period, required results, and process for submitting a rejection. Payment milestones and any provision treating silence or use as acceptance require comparison with that process.

For a payment integration, acceptance criteria might address what happens when an invoice expires, a payment notification arrives twice, or a connection to the payment service fails. The technical team defines and evaluates those scenarios. Counsel can ensure that the agreement identifies the promised behavior and the remedy when the delivered software does not meet it.

Correcting a failure to meet agreed specifications and adapting software to a subsequent change can involve different obligations. The maintenance provisions should identify who handles changes in dependencies or provider interfaces, how requests are prioritized, and which services require additional payment. A defined correction obligation also requires a duration, reporting procedure, and remedy if the developer fails to perform.

Remedies and Handoff

Contractual limits on recovery can reduce the amount the business recovers for a breach. A cap tied to development fees may be substantially below the loss associated with an unauthorized transfer or prolonged outage. The review should address which losses are excluded, which conduct is subject to the cap, and whether obligations concerning confidentiality or infringement receive different treatment.

Handoff should be part of the engagement from the beginning. The business requires the agreed code, documentation, licenses, and administrative access to continue operating through a replacement developer. You should establish delivery milestones for those materials and address what happens to completed and unfinished deliverables if either party terminates the engagement.

When the engagement ends, your business should have the rights, materials, and access necessary to continue operating and maintaining the product. Ownership provisions, delivery milestones, and termination terms should address that result before development begins.