A commitment you can inspect
A fixed transfer, a named provider and a bond reserved for that task alone
Local prototype — not audited or deployed
Two contributions with different jobs
The customer prefunds the transfer amount and service fee when creating the task
The provider deposits a separate bond when accepting those fixed terms
| Contribution | Reserved when | Purpose |
|---|---|---|
| Amount and fee | The customer creates a task | Fund the transfer and completed service |
| Provider bond | The named provider accepts | Back this task with a bounded failure payment |
Each new acceptance requires another deposit from the provider
Collateral already reserved for one task cannot be counted toward another acceptance
The workspace starts with explicitly labelled test balances and deducts each contribution as it is reserved
Its global ledger accounts for available funds, task funds, bonds and recipient credits together
The window has a strict end
A task fixes its earliest execution time and deadline before acceptance
A start time already in the past allows immediate execution within the remaining window
| Moment | Execute transfer | Settle timeout |
|---|---|---|
| Before start | Unavailable | Unavailable |
| At start, before deadline | Named provider may execute | Unavailable |
| At or after deadline | Closed | Anyone may trigger the fixed payment |
executeAfter ≤ timestamp < deadline
The contract uses chain timestamps
The workspace uses a manually advanced test clock shared by every local task
Reaching a deadline does not send a transaction or automatically settle a task
Execution and settlement both need an external caller onchain
One reservation reaches one final outcome
Completed
The dedicated transfer path sends the exact amount to the specified recipient
The provider earns the service fee and receives its bond back
Timed out
The customer receives the unused amount and fee plus the fixed failure payment from this task bond
The provider does not earn the fee and cannot execute the task afterward
Cancelled by agreement
Both named parties approve cancellation
The customer receives the amount and fee back and the provider recovers its bond without a failure payment
One approval can be revoked and does not pause execution, stop timeout settlement or change the deadline
Mutual cancellation remains possible after the deadline until another final settlement has occurred
Never accepted
The customer can withdraw an open task
Anyone can close an unaccepted expiry after its deadline, returning only the prefunded amount and fee
No provider accepted that obligation or reserved a bond, so no failure payment exists
A fixed transfer core
The Solidity prototype performs the transfer directly and checks exact balance changes
It does not treat a submitted transaction hash or an arbitrary external call as proof of completion
Each escrow instance has one immutable asset and no administrative withdrawal or upgrade mechanism
Its ledger separately records task funds and accepted bonds
createTaskCustomer
Names the provider and recipient and prefunds the amount and fee with fixed time and bond terms
acceptTaskNamed provider
Accepts an open task before its deadline and deposits new collateral equal to the bond
executeNamed provider
Executes the exact transfer within its window and atomically releases the fee and bond
settleTimeoutAnyone
Settles an accepted expired task, always paying its refund and fixed failure payment to the customer
approveCancellationEither party
Records that party approval and settles only when both parties have agreed
revokeCancellationEither party
Revokes only that party approval while the accepted task remains unsettled
withdrawOpenTaskCustomer
Withdraws an unaccepted task without creating a provider penalty
expireOpenTaskAnyone
Returns expired unaccepted task funds to their customer
Local EVM tests cover funding, actor permissions, start and deadline boundaries, separate collateral, terminal outcomes, cancellation consent and unsupported asset failures
Tests also exercise a token callback against the reentrancy guard and check rollback when a transfer fails
The bundle includes source, test fixtures, compiler settings, dependency lockfile and reproduction instructions
Mocks and ephemeral local accounts are for tests only
The core uses OpenZeppelin SafeERC20 and its storage-based ReentrancyGuard
What remains outside the commitment
Asset behavior
Only conventional assets with exact transfer accounting are in scope
Taxes, rebases, freezes and asset upgrades can make a task fail or leave funds stuck
Balance checks reject several unsupported behaviors but do not establish that any arbitrary token is safe
Direct token donations remain unallocated and have no recovery path in this prototype
Network and execution service
Robinhood Chain is the target network
The local contract tests do not establish deployment compatibility, uptime or transaction inclusion on that network
Wallet connection reads accounts and testnet balances only
No keeper, operator marketplace or gas sponsorship has been implemented
Read the official Robinhood Chain documentation
Review and financial scope
The contract core is an unreviewed prototype and the website is a separate browser-local model
Independent contract review, network testing and deployment remain necessary before handling real assets
A fixed execution bond does not guarantee investment returns or cover every market loss, opportunity cost or principal risk
Local workspace data
Workspace exports replay the local action history to reconstruct balances and terms
They are editable simulation data rather than signed evidence or blockchain receipts
Browser storage can be cleared or become unavailable
Export the workspace to retain an independent copy and use example data in this release