notegio / openrelay Goto Github PK

Overview
Apply styling to the Set Token Allowance widget.

Specifications
Styling should fit within the following constraints to the extent possible/reasonably feasible. Where intentional deviations are made, please explain to the best of your ability in commit comments.

1. OpenRelay Colors
   #003ea3, #000330, #101e62, #00288b, #2e6dd3, #0056bb, #809dff

2. 1px solid borders wherever possible.

3. Sans serif font hierarchy: Avenir Next, Helvetica Neue, Open Sans, Sans Serif

4. Use thin weights for large headings and heavy weights for user inputs and labels, as exemplified by https://get.embiggen.me.

5. Use #00223a as text color.

6. Optimize for mobile and test your results to confirm they work in Cipher, imToken and Coinbase Wallet's dApp browsers. (formerly Toshi)

7. Refer to https://fling.openrelay.xyz/ as a general style guide if no other specification speaks to a decision you're trying to make about how to implement a style.

8. Default styling should be implemented in a way that makes it easy for custom styles to be implemented without extraordinary effort.

The fill checker is a component that reads in orders and annotates them with the amount filled and amount cancelled. For the initial ingest, the vast majority of the orders we receive will not be filled or cancelled, but we still need to check because we don't want spammers to be able to spam us with a bunch of orders that have already been cancelled.

RPC lookups are the weak point in our stack right now. If we had a flood of orders come in, having to check every one of them against an RPC node when the vast majority will come back empty puts an unnecessary strain on our RPC server.

Instead, we should monitor the exchange contract and when we see our orders get filled or cancelled we should put the order hash into a bloom filter. The bloom filter will need to be populated from the point when the exchange contract was deployed, potentially excluding orders that are already expired (as they'd get filtered out anyway).

When the fill checker receives an order, it can quickly check the bloom filter to see if the order has been filled or cancelled. If the bloom filter indicates the order has been filled or cancelled, we run the RPC calls to get the details. Otherwise we forward it with fill and cancel values of 0.

We can tolerate a fairly large error rate from our bloom filter. Since bloom filters only give false positives and never false negatives, the only risk is that we run RPC calls that come back as '0'. If the bloom filter tells us it has never seen an address, we can be certain that the correct fill and cancel values are 0.

Hey, I read on your blog:

We have no immediate plans to support Kovan or Rinkeby, but are open to doing so if there is significant interest.

Just wanted to show interest from the Melon team for Kovan test net support for our testing needs. This would make the OpenRelay orderbook accessible to Melon Fund Managers on the main net on our next launch scheduled in a few weeks, where users will be incentivized to perform as many trades as possible.

Here is my email if you're interested in discussing more: [email protected]

Overview
Translate the textual elements of the Set Token Allowance widget into a language in which you are fluent or native.

Specifications
Currently we use Google Translate to support internationalization of our widgets as placeholders for more culturally-aware translations. Please correct these translations as necessary to eliminate potential mistakes in the machine-composed translations.

Overview
Translate the textual elements of the Sign Hash widget into a language in which you are fluent or native.

Specifications
Currently we use Google Translate to support internationalization of our widgets as placeholders for more culturally-aware translations. Please correct these translations as necessary to eliminate potential mistakes in the machine-composed translations.

Overview
Implement a LitElement that accepts signed order hashes as input, applies signatures to input hashes, and outputs signed orders.

Specifications

1. The widget should work within the existing architecture of the OpenRelay LitElement framework.
2. The widget should be able to accept any outputs generated by other widgets in the framework that assemble unsigned orders.
3. The widget should follow naming and syntax conventions established by already-existing widgets in the OpenRelay LitElement framework to the extent possible.

Overview
Apply styling to the Sign Hash widget.

Specifications
Styling should fit within the following constraints to the extent possible/reasonably feasible. Where intentional deviations are made, please explain to the best of your ability in commit comments.

1. OpenRelay Colors
   #003ea3, #000330, #101e62, #00288b, #2e6dd3, #0056bb, #809dff

2. 1px solid borders wherever possible.

3. Sans serif font hierarchy: Avenir Next, Helvetica Neue, Open Sans, Sans Serif

4. Use thin weights for large headings and heavy weights for user inputs and labels, as exemplified by https://get.embiggen.me.

5. Use #00223a as text color.

6. Optimize for mobile and test your results to confirm they work in Cipher, imToken and Coinbase Wallet's dApp browsers. (formerly Toshi)

7. Refer to https://fling.openrelay.xyz/ as a general style guide if no other specification speaks to a decision you're trying to make about how to implement a style.

8. Default styling should be implemented in a way that makes it easy for custom styles to be implemented without extraordinary effort.

Note: This widget is already complete, so it does not first need to be constructed before this ticket can proceed.

We should document the deployment process in case anyone else wants to run OpenRelay.

Overview
Implement a LitElement that enables users to fill an order at the price specified by particular makers. In other words, it should allow users to fill orders at a given maker-established price point up to the amount of a particular token pair they own.

Specifications

1. The widget should work within the existing architecture of the OpenRelay LitElement framework.
2. The widget should follow naming and syntax conventions established by already-existing widgets in the OpenRelay LitElement framework to the extent possible.

Overview
Apply styling to the Market Fill widget (Taker Price variant)

Specifications
Styling should fit within the following constraints to the extent possible/reasonably feasible. Where intentional deviations are made, please explain to the best of your ability in commit comments.

1. OpenRelay Colors
   #003ea3, #000330, #101e62, #00288b, #2e6dd3, #0056bb, #809dff

2. 1px solid borders wherever possible.

3. Sans serif font hierarchy: Avenir Next, Helvetica Neue, Open Sans, Sans Serif

4. Use thin weights for large headings and heavy weights for user inputs and labels, as exemplified by https://get.embiggen.me.

5. Use #00223a as text color.

6. Optimize for mobile and test your results to confirm they work in Cipher, imToken and Coinbase Wallet's dApp browsers. (formerly Toshi)

7. Refer to https://fling.openrelay.xyz/ as a general style guide if no other specification speaks to a decision you're trying to make about how to implement a style.

8. Default styling should be implemented in a way that makes it easy for custom styles to be implemented without extraordinary effort.

I've been trying to get orders from https://api.openrelay.xyz/v0
I've used ZeroEx api and @0xproject/connect to do this. And I'm using Ropstan Test Network.

Here is the flow and code I've used:

1. firstly I've created an PagedRequestOpts object:

var PagedRequestOpts = {
page: 1,
perPage: 100,
};

2. Then I created OrderRequestOpts object:
	```
var OrderRequestOpts = {
        exchangeContractAddress: selectedNetworkObj.exchangeContractAddress,
        feeRecipient: '', // feeRecipient is not defined so leaving empty
        maker: web3.eth.accounts[0],
        makerTokenAddress: selectedNetworkObj.makerTokenAddress,
        taker: ZeroEx.NULL_ADDRESS,
        takerTokenAddress: selectedNetworkObj.takerTokenAddress,
        tokenAddress: selectedNetworkObj.makerTokenAddress, // not sure which parameter to send
        trader: web3.eth.accounts[0],
    };

3. Then use these objects to create requestOpts object

var requestOpts = {
OrderRequestOpts: OrderRequestOpts,
PagedRequestOpts: PagedRequestOpts,
};

4. Then Trying to send requestOpts object in getOrderAsync method as argument to get the response promise:
	```
var ordersPromise = httpClient.getOrdersAsync(requestOpts);
	    ordersPromise.then(function(orders) {
		console.log(orders)
		for (var order of orders) {
		    showOrder(order);
		}
	    });

Here is the problem I'm facing:
while trying to get orders from 'https://api.openrelay.xyz/v0' using 0xproject/connect api method getOrdersAsync I'm getting the same order over and over. And that order is not even related to my request. Am I doing anything wrong? please help me.

Btw The requestOpts object that I'm passing in getOrderAsync function is :

"{"OrderRequestOpts":{"exchangeContractAddress":"0x479cc461fecd078f766ecc58533d6f69580cf3ac","feeRecipient":"","maker":"0xe60c537190939913291db1296a8758b654519e46","makerTokenAddress":"0xa8e9fa8f91e5ae138c74648c9c304f1c75003a8d","taker":"0x0000000000000000000000000000000000000000","takerTokenAddress":"0xc778417e063141139fce010982780140aa0cd5ab","tokenAddress":"0xa8e9fa8f91e5ae138c74648c9c304f1c75003a8d","trader":"0xe60c537190939913291db1296a8758b654519e46"},"PagedRequestOpts":{"page":1,"perPage":100}}"

Here I'm showing it by stringifying. but in code I'm sending it as object.
And the array of order object I'm getting is:
"[{"maker":"0xe689f23ae131e18356aeb130917ca510ee454033","taker":"0x0000000000000000000000000000000000000000","makerTokenAddress":"0xa1df88ea6a08722055250ed65601872e59cddfaa","takerTokenAddress":"0xc778417e063141139fce010982780140aa0cd5ab","feeRecipient":"0xc22d5b2951db72b44cfb8089bb8cd374a3c354ea","exchangeContractAddress":"0x479cc461fecd078f766ecc58533d6f69580cf3ac","makerTokenAmount":"1000000000000000000","takerTokenAmount":"1000000000000000000","makerFee":"250000000000000000","takerFee":"250000000000000000","expirationUnixTimestampSec":"1525030534","salt":"1524166534","ecSignature":{"v":28,"r":"0xf8f601793caf4d1596cf5d1324ff3e51a004d99e0d147bd9b5735af376be8dc9","s":"0x1c6e12fce632f92d722496b637b9830ecd797e8eff50524226d857ac1ee42bd1"}}]"

Thank you in advance.
regards

Right now we're using Redis for both message queues and topics. This mostly works, but Redis doesn't automatically return messages to the queue if the fail to process, and Redis is likely to be a key bottleneck as we try to scale.

We should continue to support Redis based queues, both for local development and for host agnosticism. Whether we go to a Redis queue or an SQS queue should be indicated by the URL passed into any given microservice's command line options.

Topics will still use Redis for the time being.

Overview
Implement a LitElement that enables search of the Standard Relayer API by token pair, and allows the results to be filtered.

Specifications

1. The widget should work within the existing architecture of the OpenRelay LitElement framework.
2. The widget should be able to filter by any metrics you deem relevant, but at a minimum should allow filtering by price and expiration time.
3. The widget should follow naming and syntax conventions established by already-existing widgets in the OpenRelay LitElement framework to the extent possible.

Notes
Radar Relay has an example in its trading UI can be used as a guide at https://app.radarrelay.com/ZRX/WETH.

Overview
Implement a LitElement that enables users to fill an order at the price specified in terms of a desired quantity, regardless of the price specified by makers, up to a specified limit. In other words, it should allow users to fill orders at a given taker-established quantity regardless of price, but should also enable users to specify a maximum price per unit they are willing to spend.

Specifications

1. The widget should work within the existing architecture of the OpenRelay LitElement framework.
2. The widget should follow naming and syntax conventions established by already-existing widgets in the OpenRelay LitElement framework to the extent possible.

There are a number of different sites dedicated to one particular token or another. We should make it as easy as possible for those sites to include a widget for buying and selling their token through OpenRelay.

If anyone has a chance to help me, I need help to build in windows 10 or ubuntu 16.0.4.
Please help me. Thanks a lot.

Overview
Translate the textual elements of the Market Fill widget (Maker Price variant) into a language in which you are fluent or native.

Specifications
Currently we use Google Translate to support internationalization of our widgets as placeholders for more culturally-aware translations. Please correct these translations as necessary to eliminate potential mistakes in the machine-composed translations.

Overview
Document the widget to aid developers in understanding how to best implement the Sign Hash widget.

Specifications
Please include, at a minimum:

1. Description and examples of how the widget should be implemented.
2. Descriptions and examples of how to use optionals.
3. Descriptions of examples of any edge-case implementation details of which you are aware, if any exist.
4. Include anything else that you think will assist developers in implementing the widget effectively.

In conversations with some potential affiliates, it would be pretty valuable to be able to support testnet. I'd like to do this with the same openrelay deployment, and support testnet by using the exchange contract address in the order to check which network to use for validating orders.

Impacts:

The fund checker and fill checker will need to be overhauled to know what network to check based on the exchange address.

We can use the same delay relay, and release testnet orders after two mainnet blocks are mined; it shouldn't matter if testnet orders are released a little early or a little late.

We'll need another exchange monitor (for fills and cancellations for the exchange on testnet.

Finally, we'll need an ethereum client for testnet.

Currently, the ingest checks that the total fee is greater than or equal to the minimum fee, but it doesn't set a maximum. Makers could potentially grief takers by listing orders with very high fees. We should ensure that the taker fee does not exceed the minimum fee, though if makers want to exceed the minimum fee that seems like their prerogative.

If one user uploads a bunch of orders with the same maker token (or the same fee token) all at once, we know the maker balance can't change between blocks, so there's no point in retrieving it multiple times. We should create a cache that gets cleared every time a new block is mined to streamline balance checking for lots of orders from the same maker.

We want to encourage third parties to build front-ends to OpenRelay. The planned model for this is that a third party can apply for an affiliate contract, providing us with an Ethereum address. We will deploy an affiliate contract which will split fees between OpenRelay.xyz and the affiliate, according to a negotiated share. The affiliate can then list the contract address as the feeRecipient in orders, openrelay.xyz will accept orders with those fee recipients, and as they are accepted both OpenRelay.xyz and the affiliate will receive portions of the fees.

We need to implement the affiliate contracts.

Given transaction confirmation times, it doesn't make sense to show a user an order that is going to expire in the next few seconds - they won't have time to get it into a block. We should probably stop returning orders a minute or two before the actual expiration time.

Hi

I am doing a make all and i get the following error. I am using mac os sierra.
Does it compile in mac os at all?

cd "/Users/zahoor/go/src/github.com/NoteGio/openrelay/.gopath/src/github.com/notegio/openrelay" && go build -a -installsuffix cgo -ldflags '-extldflags "-static"' -o bin/delayrelay cmd/delayrelay/main.go
# command-line-arguments
/usr/local/go/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

make: *** [bin/delayrelay] Error 2

The current Orderbook Backend is DynamoDB. This was a good way to get up and running quickly and cheaply, but has its limitations.

First, it would be good to have an option that did not bind us to a particular hosting provider.

Second, we need more advanced querying capabilities. DynamoDB only allows for 5 global secondary indexes, but to comply with the standard relayer API efficiently we would need at least 6.

At this point, we haven't decided what the successor to DynamoDB will be, and to some degree we want to wait until after 2017's AWS Reinvent to see if that changes the dynamic.

Considerations for new backends:

• We have a rigid schema, and know the exact bytes that will be provided. We don't need a generic document store or full text search.
• Eventual consistency is okay. We aren't dependent on writes being immediately reflected in reads, and we have a long processing pipeline between user submissions and orders being searchable anyway.
• We do need to be able to support several query indexes, and semi-complex sorting options.

We should use Docker's Multi-stage Builds to create our Docker images, I believe that can simplify our instructions to get an environment up and running from:

• Use Linux
• Get the Go Toolchain
• Get Docker
• Run the make command
• Run Docker Compose

to:

• Get Docker
• Run Docker Compose

Allowing us to support development on a wider variety of platforms, and reduce the setup process.

The Fill Updater isn't programmed to Ack messages, and thus they just pile up in the unacked queue.

Similarly, the Delay Relay isn't Ack'ing the sentinel messages, though at this point I'm not sure why.

Overview
Document the widget to aid developers in understanding how to best implement the SRA Search / Filter widget.

Specifications
Please include, at a minimum:

1. Description and examples of how the widget should be implemented.
2. Descriptions and examples of how to use optionals.
3. Descriptions of examples of any edge-case implementation details of which you are aware, if any exist.
4. Include anything else that you think will assist developers in implementing the widget effectively.

When the fundchecker can't communicate with the Ethereum Node, it reports all orders as lacking funds. It's bad enough that this means we can't ingest new orders while the Ethereum node is down, but the periodic rechecks of funds flag them all as insufficient and remove them from the orderbook.

Obviously we want to make sure that the Ethereum node is available as much as possible, but in the event that it does go down, it shouldn't empty the orderbook immediately.

Intermittently, requests made to api.openrelay.xyz come back with a 502 error.

Currently, order expiration is checked by the order queuing service, so expired orders are being pruned, but we should reject orders in the ingest process if their expiration is less than a minute in the future.

Overview
Document the widget to aid developers in understanding how to best implement the Signed Order widget.

Specifications
Please include, at a minimum:

1. Description and examples of how the widget should be implemented.
2. Descriptions and examples of how to use optionals.
3. Descriptions of examples of any edge-case implementation details of which you are aware, if any exist.
4. Include anything else that you think will assist developers in implementing the widget effectively.

Overview
Translate the textual elements of the SRA Search / Filter widget into a language in which you are fluent or native.

Specifications
Currently we use Google Translate to support internationalization of our widgets as placeholders for more culturally-aware translations. Please correct these translations as necessary to eliminate potential mistakes in the machine-composed translations.

The current monitoring services (the exchange fill monitor and the block monitor) use HTTP polling to monitor for changes. This means:

• We have extra traffic going back and forth between services
• We can't trivially load-balance the monitoring services, because they need to talk to the same backend consistently.

Geth supports a websockets subscription endpoint that can provide the same information over a websockets connection, which would have less back-and-forth traffic, and would mean we could establish a connection with any available Ethereum node and it would be good for the life of the connection.

While the documentation provides tutorials on interacting with OpenRelay, things would be simplified by a unified SDK. Since one of the early goals is to create a portal site, a JavaScript SDK is a good place to start.

OpenRelay uses HAProxy in front of the Ethereum RPC service, the intent being that if the state node or monitor node becomes unavailable, it can fall back to the standby node and eventually the RPC node serving the other purpose.

We're seeing a couple of issues with the current configuration. First, HAProxy is only resolving IPs at startup, so if a server goes down and comes back with a different address, HAProxy never routes requests there. Second, HAProxy won't come up until all of the Ethereum servers are available. So if the standby server is down and HAProxy gets restarted, HAProxy won't come back up until the standby node is back up, even though the primary node was available.

I believe this can be fixed in the HAProxy config, as discussed here: https://discourse.haproxy.org/t/haproxy-fails-to-start-if-backend-server-names-dont-resolve/322/17

Alternatively, if we can resolve #8 I think we can just go to one big pool of Ethereum nodes and not need to use HAProxy at all. That's probably a larger topic though than tweaking the HAProxy config.

Since we're already generating and using Docker images, it would be good to incorporate deploying them to DockerHub instead of just the AWS ECR, so they'll be available to other people.

We've seen some people accidentally submit orders with the expiration timestamp specified in milliseconds instead of seconds, so while they might have intended for the order to expire in a few hours, it actually expires in about fifty thousand years. We're fine with people posting really long term orders, but we should probably reject orders with timestamps that look like they're off by a few orders of magnitude.

Overview
Translate the textual elements of the Signed Order widget into a language in which you are fluent or native.

Specifications
Currently we use Google Translate to support internationalization of our widgets as placeholders for more culturally-aware translations. Please correct these translations as necessary to eliminate potential mistakes in the machine-composed translations.

Overview
Document the widget to aid developers in understanding how to best implement the Market Fill widget (Maker Price variant).

Specifications
Please include, at a minimum:

1. Description and examples of how the widget should be implemented.
2. Descriptions and examples of how to use optionals.
3. Descriptions of examples of any edge-case implementation details of which you are aware, if any exist.
4. Include anything else that you think will assist developers in implementing the widget effectively.

Overview
Apply styling to the Signed Order widget.

Specifications
Styling should fit within the following constraints to the extent possible/reasonably feasible. Where intentional deviations are made, please explain to the best of your ability in commit comments.

1. OpenRelay Colors
   #003ea3, #000330, #101e62, #00288b, #2e6dd3, #0056bb, #809dff

2. 1px solid borders wherever possible.

3. Sans serif font hierarchy: Avenir Next, Helvetica Neue, Open Sans, Sans Serif

4. Use thin weights for large headings and heavy weights for user inputs and labels, as exemplified by https://get.embiggen.me.

5. Use #00223a as text color.

6. Optimize for mobile and test your results to confirm they work in Cipher, imToken and Coinbase Wallet's dApp browsers. (formerly Toshi).

7. Refer to https://fling.openrelay.xyz/ as a general style guide if no other specification speaks to a decision you're trying to make about how to implement a style.

8. Default styling should be implemented in a way that makes it easy for custom styles to be implemented without extraordinary effort.

This is an older ticket, but it looks like it may be finally getting some legs, so I'm writing it up in more detail.

We need a microservice that implements the Websockets version of the Standard Relayer API.

The microservice will subscribe to a list of channels. Whenever an order comes in on any of the channels, the microservice will iterate over its list of websocket subscribers, check whether the order matches the filters of each subscriber, and send the order to the subscriber if it matches.

The websocket portion of the service should probably use Gorilla Websockets to upgrade HTTP connections into Websockets Connections. When a user submits a "subscribe" message as laid out in the Standard Relayer API, it should create a subscription object that includes.

Subscription Object

The Subscription object should include:

• The request ID
• A filter object
• A chan *types.Order channel, which should be sent orders that match the filter.
• A boolean indicating whether the channel is still open.

Subscriptions should have a Dispatch(*types.Order) method, which will be called on all available orders. The dispatch method should evaluate the received order against the filter object. If the object matches the filter and the connection is still open, the order should be sent over the subscription's channel

Filter Object

The filter object should have attributes for:

• makerAssetProxyId ([4]byte)
• takerAssetProxyId ([4]byte)
• makerAssetAddress (*types.Address)
• takerAssetAddress (*types.Address)
• makerAssetData (*types.AssetData)
• takerAssetData (*types.AssetData)
• traderAssetData (*types.AssetData)
• networkId (int)

It should include a Filter(*types.Order) method. Which should return true if the message should be forwarded, false otherwise. The filter method should check each property of the filter. If the filter property is null, then no checks are necessary. If the filter property is non-null, it should be compared against the corresponding order property or properties. If the properties match, it should continue to the next property, otherwise it should return false.

Websocket Goroutine

When a user connects via websockets, the HTTP process will instantiate a new Goroutine for that user and call the handler function. Our handler function should upgrade the connection to a websockets request. After upgrading, the handler function should:

1. Create an order channel

2. Create a go routine to watch that order channel

3. When orders come in through that order channel, serialized them based on github.com/notegio/openrelay/search.GetFormattedOrder() and sent over the channel.

   GetFormattedOrder() takes a *db.Order rather than a *types.Order. For this, we can construct a *db.Order given the *types.Order(see github.com/notegio/openrelay/db/indexer.go - index function), then call order.Populate() to fill in the other necessary details.

4. Read for new messages on the websockets connection. If it gets a subscription message, it should:

   1. Construct a subscription object based on the incoming message
   2. Add the new subscription object to a global list of subscriptions (iterate over the list of subscriptions and replace the first subscription where the "active" boolean field for the subscription is False, or append a new one to the end if none are inactive).
   3. Spin off a new goroutine to watch the channel for that subscription
   4. In the new goroutine, when messages come in on the subscription channel, simply relay them to the websocket's order channel (it needs to go through that channel because only one goroutine at a time is allowed to write to the socket, so we'll just pass messages to that goroutine).

5. If a message comes in indicating that the socket has closed, or if a write operation to the websocket fails, mark the subscription as inactive.

Consumer

Each channel we listen on will require a Consumer implementing the github.com/notegio/openrelay/channels/consumer.Consumer interface. The Consume(Delivery) method will be called each time an order is received. The consumer should iterate over the list of subscriptions, calling Dispatch on each. These should be added to ConsumerChannels, following the same pattern as most of the other OpenRelay consumers.

Command

The structure of the command for this microservice will be comparable to that of cmd/searchapi/main.go. It will have one API endpoint, a list of Consumers. The command line arguments will consist of the redis URL and a list of channels to watch. The channels should be converted to ConsumerChannels using the channels.ConsumerFromURI method, allowing it to operate from both Topic and Queue based channels.

Testing

This service can be tested in several smaller units:

Filters can simply be tested by checking whether a filter matches a provided order as expected.

Subscriptions can be tested by passing calling Dispatch() and testing whether the order goes on the channel as expected.

Testing the websockets piece will require a websockets client implemented in Go that sends the appropriate subscription messages, and watches for orders to come back as expected. Sending orders to the consumers that will dispatch through the websockets can be done with the MockChannel library.

APIs are great, but if any non-coders are going to use openrelay we're going to need a portal site.

Overview
Implement a LitElement that enables users to set a token allowance for any token.

Specifications

1. The widget should work within the existing architecture of the OpenRelay LitElement framework.
2. The widget should be able to set allowances for any type of token that requires it, including custom tokens.
3. The widget should follow naming and syntax conventions established by already-existing widgets in the OpenRelay LitElement framework to the extent possible.

OpenRelay should aim to comply with the 0x Standard Relayer API

Overview
Document the widget to aid developers in understanding how to best implement the Set Token Allowance widget.

Specifications
Please include, at a minimum:

1. Description and examples of how the widget should be implemented.
2. Descriptions and examples of how to use optionals.
3. Descriptions of examples of any edge-case implementation details of which you are aware, if any exist.
4. Include anything else that you think will assist developers in implementing the widget effectively.

The postgres orderbook is listing some expired orders.

The DynamoDB orderbook delists orders via the queue_orders microservice. The first time it iterates over an order after it expires, it gets deleted from Dynamodb. Right now the Postgres orderbook is dependent on the dynamodb queue_orders service, but since the dynamodb queue orders service just deletes expired orders and doesn't queue them, they never get removed from postgres.

We should filter searches and orderbook requests based on the ExpirationTimestampInSec value. We're storing that value as bytes, but if we convert the current time at the moment of a search to bytes we should be able to do comparison to filter out expired orders.

Overview
Apply styling to the Market Fill widget (Maker Price variant).

Specifications
Styling should fit within the following constraints to the extent possible/reasonably feasible. Where intentional deviations are made, please explain to the best of your ability in commit comments.

1. OpenRelay Colors
   #003ea3, #000330, #101e62, #00288b, #2e6dd3, #0056bb, #809dff

2. 1px solid borders wherever possible.

3. Sans serif font hierarchy: Avenir Next, Helvetica Neue, Open Sans, Sans Serif

4. Use thin weights for large headings and heavy weights for user inputs and labels, as exemplified by https://get.embiggen.me.

5. Use #00223a as text color.

6. Optimize for mobile and test your results to confirm they work in Cipher, imToken and Coinbase Wallet's dApp browsers. (formerly Toshi)

7. Refer to https://fling.openrelay.xyz/ as a general style guide if no other specification speaks to a decision you're trying to make about how to implement a style.

8. Default styling should be implemented in a way that makes it easy for custom styles to be implemented without extraordinary effort.

The 0x team has implemented an OrderWatcher as part of 0x.js, which can monitor for order invalidations more efficiently than the queue_order service and subsequent pipeline. We should build a microservice off of this to replace the fill order monitor, as well as the queue order service and subsequent pipeline.

Overview
Apply styling to the SRA Search / Filter widget.

Specifications
Styling should fit within the following constraints to the extent possible/reasonably feasible. Where intentional deviations are made, please explain to the best of your ability in commit comments.

1. OpenRelay Colors
   #003ea3, #000330, #101e62, #00288b, #2e6dd3, #0056bb, #809dff

2. 1px solid borders wherever possible.

3. Sans serif font hierarchy: Avenir Next, Helvetica Neue, Open Sans, Sans Serif

4. Use thin weights for large headings and heavy weights for user inputs and labels, as exemplified by https://get.embiggen.me.

5. Use #00223a as text color.

6. Optimize for mobile and test your results to confirm they work in Cipher, imToken and Coinbase Wallet's dApp browsers. (formerly Toshi)

7. Refer to https://fling.openrelay.xyz/ as a general style guide if no other specification speaks to a decision you're trying to make about how to implement a style.

8. Default styling should be implemented in a way that makes it easy for custom styles to be implemented without extraordinary effort.