> ## Documentation Index > Fetch the complete documentation index at: https://docs.0xmonaco.com/llms.txt > Use this file to discover all available pages before exploring further. # Set your builder fees > Set this application's builder fees. The builder fee is an additional taker fee, in basis points, that this frontend charges its own users on top of Monaco's fee when their order fills as the taker. The maker add-on is the same for a user's order that fills as the maker: it is paid by the maker on top of Monaco's maker fee or rebate. The application is taken from the authenticated session; the caller must be the application's BuilderCodes payout wallet, and delegated-agent sessions are refused. `bps` (taker) is required. `makerBps` is optional; omitting it leaves the maker add-on unchanged. Each must be between 0 and the current builder-fee cap (`builderFeeCapBps` on `GetBuildercodesConfig`) inclusive; the cap and the switches are shared by both sides. The application must be enrolled in BuilderCodes with a payout address. At most two changes are allowed in any rolling 24 hours, and one call that sets both sides is one change; changes Monaco makes on the application's behalf do not count. Setting the values it already has is a no-op that succeeds and does not use up a change. The fees can be set while the revenue share or builder fees are switched on, and are refused (**HTTP 403** / **PERMISSION_DENIED**) while both are off. With builder fees off (`builderFeeEnabled` false) they are stored and nothing is charged until they are switched on. A newly stored taker fee reaches order requests within a few seconds. A newly stored maker add-on applies to orders placed after the matching engine's next BuilderCodes enrollment refresh, shortly after it is saved; an order resting on the book keeps the maker add-on in force when it was placed. Sequencer ordering is authoritative for matching-engine policy and enrollment state: an order processed before one of those sequenced changes uses the earlier state, and a later order uses the new state. A refused change is **HTTP 409** / **FAILED_PRECONDITION** when the application is not enrolled with a payout address or has no changes left (REST adds `details.nextChangeAllowedAt`), and **HTTP 400** / **INVALID_ARGUMENT** when `bps` or `makerBps` is above the cap. ## OpenAPI ````yaml /proto-openapi/api/openapi.yaml put /api/v1/buildercodes/builder-fee openapi: 3.0.3 info: title: Monaco Protocol API description: REST API for the Monaco Protocol hybrid CLOB exchange. version: 1.0.0 servers: - url: https://staging.apimonaco.xyz description: Staging server (Testnet) security: [] tags: - name: AccountsService - name: ApplicationsService - name: AuthService - name: BuildercodeRewardsService - name: CopyTradingService - name: DelegatedAgentsService - name: FaucetService - name: FeesService - name: HealthService - name: ManagedMarketsService description: |- Wallet-authenticated maker assignments. The signed session must match both configured maker user and application. Owner IDs are process fences, never auth. Only wallet sessions are supported; delegated-agent sessions receive 403. - name: MarginAccountsService description: |- Current public isolated-margin semantics: - a user has one parent margin account per application scope - opening orders create or reuse isolated position buckets under that parent - parent account creation is handled internally by margin workflows - name: MarketService - name: OrderbookService - name: OrdersService - name: PositionsService description: |- Current public isolated-margin semantics: - positions link to a parent margin account and, when applicable, a bucket id - opening orders create or reuse isolated position buckets under the parent - users can open another isolated position by reusing the parent account with a different market bucket - name: PulseService - name: SweeperService - name: TraderCodeService - name: TradesService - name: WhitelistService - name: WithdrawalsService paths: /api/v1/buildercodes/builder-fee: put: tags: - BuildercodeRewardsService - BuilderCodes summary: Set your builder fees description: |- Set this application's builder fees. The builder fee is an additional taker fee, in basis points, that this frontend charges its own users on top of Monaco's fee when their order fills as the taker. The maker add-on is the same for a user's order that fills as the maker: it is paid by the maker on top of Monaco's maker fee or rebate. The application is taken from the authenticated session; the caller must be the application's BuilderCodes payout wallet, and delegated-agent sessions are refused. `bps` (taker) is required. `makerBps` is optional; omitting it leaves the maker add-on unchanged. Each must be between 0 and the current builder-fee cap (`builderFeeCapBps` on `GetBuildercodesConfig`) inclusive; the cap and the switches are shared by both sides. The application must be enrolled in BuilderCodes with a payout address. At most two changes are allowed in any rolling 24 hours, and one call that sets both sides is one change; changes Monaco makes on the application's behalf do not count. Setting the values it already has is a no-op that succeeds and does not use up a change. The fees can be set while the revenue share or builder fees are switched on, and are refused (**HTTP 403** / **PERMISSION_DENIED**) while both are off. With builder fees off (`builderFeeEnabled` false) they are stored and nothing is charged until they are switched on. A newly stored taker fee reaches order requests within a few seconds. A newly stored maker add-on applies to orders placed after the matching engine's next BuilderCodes enrollment refresh, shortly after it is saved; an order resting on the book keeps the maker add-on in force when it was placed. Sequencer ordering is authoritative for matching-engine policy and enrollment state: an order processed before one of those sequenced changes uses the earlier state, and a later order uses the new state. A refused change is **HTTP 409** / **FAILED_PRECONDITION** when the application is not enrolled with a payout address or has no changes left (REST adds `details.nextChangeAllowedAt`), and **HTTP 400** / **INVALID_ARGUMENT** when `bps` or `makerBps` is above the cap. operationId: set_builder_fee requestBody: content: application/json: schema: $ref: '#/components/schemas/SetBuilderFeeRequest' required: true responses: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/SetBuilderFeeResponse' '400': description: >- bps or makerBps is above the current builder-fee cap (gRPC: INVALID_ARGUMENT) '401': description: Authentication required '403': description: >- Refused: neither the revenue share nor builder fees are switched on, the caller is delegated, or the caller is not this application's payout wallet (gRPC: PERMISSION_DENIED) '404': description: 'Authenticated application not found (gRPC: NOT_FOUND)' '409': description: >- The application is not enrolled in BuilderCodes with a payout address, or it has already made two changes in the last 24 hours; the latter carries `details.nextChangeAllowedAt` (gRPC: FAILED_PRECONDITION) '500': description: Internal server error security: - monacoSignature: [] - monacoHttpSignature: [] components: schemas: SetBuilderFeeRequest: required: - bps type: object properties: bps: example: 10 maximum: 100 type: integer description: >- New builder fee in basis points, from 0 up to the current `builderFeeCapBps` inclusive. 0 stops charging a builder fee. format: uint32 makerBps: example: 5 maximum: 100 type: integer description: >- New maker add-on in basis points, from 0 up to the current `builderFeeCapBps` inclusive. Omit to leave the maker add-on unchanged; 0 stops charging one. It applies to orders placed after the matching engine's next BuilderCodes enrollment refresh, shortly after it is saved, and never to an order already resting. format: uint32 nullable: true additionalProperties: false SetBuilderFeeResponse: type: object properties: builderFeeBps: example: 10 maximum: 100 type: integer description: The builder fee now stored, in basis points. format: uint32 nullable: true previousBuilderFeeBps: example: 0 maximum: 100 type: integer description: >- The builder fee this change replaced, in basis points. Equal to `builderFeeBps` when the request set the fee it already had, which changes nothing. format: uint32 nullable: true changesRemaining: example: 1 maximum: 2 type: integer description: >- Builder-fee changes this application can still make in the current rolling 24 hours (at most 2). format: uint32 nullable: true nextChangeAllowedAt: type: string description: >- RFC 3339 time at which the next builder-fee change becomes allowed, or null while `changesRemaining` is above 0. format: date-time nullable: true builderMakerFeeBps: example: 5 maximum: 100 type: integer description: >- The maker add-on now stored, in basis points. It applies to orders placed after the matching engine's next BuilderCodes enrollment refresh, shortly after it is saved; orders already resting keep the rate they were placed with. format: uint32 nullable: true previousBuilderMakerFeeBps: example: 0 maximum: 100 type: integer description: >- The maker add-on this change replaced, in basis points. Equal to `builderMakerFeeBps` when the request left it unchanged. format: uint32 nullable: true securitySchemes: monacoSignature: type: apiKey description: >- Ed25519 session-key request signing. Every authenticated request carries three headers: `X-Monaco-PublicKey` (64-char lowercase-hex session public key), `X-Monaco-Timestamp` (Unix milliseconds, within 30s of server time), and `X-Monaco-Signature` (hex ed25519 signature). The signature is over `METHOD\npath?query\ntimestamp_ms\nSHA256_hex(body)`, where the body hash is the SHA-256 of the empty byte string when there is no body. Obtain the session keypair from `POST /api/v1/auth/challenge` followed by `POST /api/v1/auth/verify`. name: X-Monaco-Signature in: header monacoHttpSignature: type: apiKey description: >- RFC 9421 Ed25519 session-key request signatures. Send Signature-Input, Signature, and Content-Digest together; never combine them with X-Monaco-* credentials. The monaco signature covers @method, @path, @query, and content-digest in that order, with created (Unix seconds within 30s of server time), keyid (registered lowercase-hex session public key), and alg=ed25519 parameters. Content-Digest uses RFC 9530 sha-256 over the exact body bytes, including the empty body. Query coverage retains ordering and percent encoding. Timestamp freshness does not reject repeated identical requests; use endpoint idempotency where supported. Existing legacy signing remains supported during server-first migration; SDK RFC 9421 signing is opt-in. See https://docs.0xmonaco.com/reference/http-message-signatures for the complete profile and trust model. name: Signature in: header ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.