Contracts are very often misunderstood and so I thought I would adapt a guidelines thread that I wrote for staff for this section, so everyone can benefit from it and hopefully speed up the process of getting your contracts approved. Public Contract Guidelines This is your go-to guide for what is currently expected in contracts. This is exactly what Staff are looking for when they examine every contract. Use this guide to prepare your contracts and help your contracts get approved faster! Below is the current policies for what is required in a contract. Spoiler: Tagging Usernames All usernames that are involved in a contract need to be tagged at least once Spoiler: Agreements All users tagged/mentioned in the contract need to agree by simply posting on the specified contract "I agree" or some form of consent to the contract If a contract has been edited and any of the parties agreed before the edit, they must post and re-agree to the edited contract Spoiler: Actions Which action(s) is each party supposed to perform. Actions that begin the contract do not need to defined to a specific time-frame. It is common sense that if A happens B will also happen. Example: I @ClarinetPhoenix will add @UnitedStates2 as owner to the town of Oasis on the Main server. @UnitedStates2 will pay me $1,000,000 ECD OR I, @ClarinetPhoenix give the town of Oasis on Main to @UnitedStates2 for $1,000,000 ECD. Both of these clauses are an acceptable, enforceable bare-bones contract that can be approved. Actions that are part of the contract after the initial transaction(s) will need to be defined within a specific time-frame. Actions that are re-occurring, such as a payment schedule should have at the very least a defined day in which that action must be performed. If there is no exact time defined with a specific timezone then it is assumed a payment is due by the end of the specified day(EST/EDT). If there is a time defined but the timezone is not specified then the timezone of EST/EDT is assumed. Any sort of phrasing or wording for the actions is acceptable as long as the purpose/intent to the contract is clear. All actions should abide by the server rules, contract clauses cannot go against any server rules. Spoiler: Assets Which assets are involved in this contract; Tools All tools that are part of a contract must be /own'd and the ID must be presented somewhere in the contract. If the contract is a tool rental, ensure the tool's rental home location(town name, or warp name, or coordinates and the server it is on) is specified in the contract. Items/Blocks Items and blocks should be specified by name and quantity or defined in a form that makes it clear/easy to track should it be necessary. Towns Towns must specified by which server the town is on and include the name of the town in the contract. Including the town's application may replace specifying the server within a clause. EcoDollars EcoDollars involved in a contract should be clearly defined either by definite number amounts or by amounts calculated with or without variables over a period time. Features and Giftcards When Features are involved the Feature(s) package should be specified in the contract. Due to sales/discounts and coupon/Giftcard usage the specific USD amount to be spent does not need to be defined. It is enough for a feature seller to promise to buy x features for x user for x price.. When Giftcards are involved, the amount of the Giftcard that is part of the contract must be defined. Giftcards can be used multiple times until they are out of credit, Users may sell partially used GC's and therefore must guarantee that amount is still on the card at the time of sale. Spoiler: Deadline and Dates Which deadlines and dates are specified; Dates should be clearly defined so that it is clearly understood. Dates are required only when something needs to be scheduled to happen during the contract. Late fees should not be open-ended and should always have an end date. They also should not be unreasonable. Payment plans should not be open-ended, all agreements should have a clearly defined end, either when a term is met or ends at a certain date. Spoiler: Shared Contracts Users may set up contracts in which two or more users are responsible for whatever amount of money is owed in the contract. For a shared contract to be approved the following requirements should be met; Payment Schedule/Responsibility. For each of the participating users the payment responsibility must be clearly defined. It must be determined that either: Each involved user pay x amount on x day(weekly/daily/monthly etc) and the payment schedule rotates so each user is paying something at intervals Example: @UnitedStates2 will pay $100,000 ECD on Sunday, August 23rd @ClarinetPhoenix will pay $100,000 ECD on Sunday, August 30th @UnitedStates2 will pay $100,000 ECD on Sunday, September 6th Each involved user pays x amount on x day on the same interval. Example: @UnitedStates2 and @ClarinetPhoenix agree to each pay $100,000 every Sunday via their respective chestshop set up at /warp highgarden on Main. Each involved user is deemed responsible for a lump sum portion of the entire contracted amount and the due date is specified. Example: @UnitedStates2 agrees to be responsible for $400,000 ECD of the $800,000 ECD amount and will pay this amount by Sunday, September 6th. @ClarinetPhoenix agrees to be responsible for $400,000 ECD of the $800,000 ECD amount and will pay this amount by Sunday, September 6th. Town Sales: A town transfer can only apply to one user, however it is possible for users to share a town. For such a contract to work; It must be determined within the contract who will have the Transfer right. It will be assumed by this term that the other users involved in the contract will automatically become co-owners to the town. All the above requirements regarding the sharing of money owed must be met. Tool Sales: Tool sales must indicate who is to take on the /own after the amount is paid in full. If the users are planning to share the tool then such terms should also be included in the contract as well. Full-Party Responsibility: The contract must include terms/provision for what happens if one or more of the users in the shared owing parties fails to uphold their part of the contract, as in pay the money/assets they agreed to pay. All users in this contract must agree to be responsible for completing the contract to make sure the amount is paid in full, including the amount that one or more of their party was responsible for should one or more users of the party drop out due to non-payment. Users can also add terms to void/discontinue a contract should such an event happen, as long as the contract is seen to some sort of end. Spoiler: Other things Staff look for when examining contracts. Clauses that are improperly defined. We use the spoilers above to determine if any of the clauses are not properly defined. Clauses that violate server rules. There especially cannot be clauses that contract a user to waive rights, protections, or participate in an action or process that is in violation of any of those established by the server rules and policies. Examples: Contracting an official owner to give up rights to reclaim the town before it is transferred. Contracting that a town co-owner may remove official owner locks in a town. Contracting an official owner to give over all official transfer rights of a town WITHOUT filing for a transfer. Contracting that less than 7 days of inactivity waives them any right to an eviction notice. These are just a few examples of clauses that would not be allowed in contracts due to conflict with the server rules. Contract cannot bind in other parties with actions/assets without directly mentioning them. This is most common with shared assets and banks/investments where the assets in question may be shared by two or more users. Town ownership is not considered a shared asset unless otherwise contracted(in the case of co-ownership). A town owner may contract with another user regarding a town without the consent of the other listed owners. If other users are to be part of the contract then they need to be properly mentioned and they will also need to agree. Contract Approval Process: This section is merely to inform you of the approval process so you may understand why contract approvals are not instantaneous. Contract Review: When a contract is posted a Staff member "claims" it and posts it in our channel on the Staff Discord. The contract is then reviewed against the above guidelines to make sure everything is all in order. Changes: If there are any issues with the contract, it is discussed and decided on what changes need to be made. Then the Staff member who has claimed the contract then posts on the contract asking for the necessary changes. The contract is then reviewed again, and if changes still need to be made this step is repeated until the contract meets the standards. Final Approval Process: Once the changes are made, and if everything checks out it is required that at least 3 Staff members indicate that the contract is good to go. This is the Staff who has claimed the contract and two others. We do this to ensure contracts are being viewed by multiple sets of eyes, and to help ensure contracts are not being rushed through without being fully examined. Approval: Once the above steps are complete, the Staff responsible for the contract will then lock your contract and approve it. You're good to go then! Contract Examples You can find a template for the most commonly made contracts here.
